Originally by: Claire Voyant

---

Isn't FIFO kind of archaic? Does it make sense to say the profit on an item is based on materials purchased maybe months ago, instead of comparing current sales price against current material cost on the market. Then you also track you inventory (both materials and finished goods) against market value and try to manage the market risk of your inventory. Either by keeping inventory as low as possible, or by "hedging" by buying inventory when prices are low and not buying when prices are high. Anyway, that is what I would do if I could be bothered.

---

Originally by: Chingyz

---

If your program is going to be used by auditors then you are looking at a bigger problem then just the pros and cons of FIFO versus average (or any of the other types of valuation). For finding profit of historic transactions then it really doesn't matter that much which type of valuation you use (although there are more benefits to FIFO). The problem lies in the valuation of your assets. When it comes to assets like stock of finished goods or raw materials it's often better to use current prices for valuation rather than FIFO. This is due to the nature of assets, which is to show what they are worth at the end of the historic period

The best way to get around this is to have several layers/pages in your program. Use one for profit calculations, based on the FIFO principle. One for assets based on current prices. This can also be used as a tool for setting sale price of your items.

---

Originally by: Varo Jan

---

His opening post deals with stock valuation only.

---

Originally by: Varo Jan

---

That&s a far cry from developing a true accounting system capable of generating cash flow P&L and balance sheet statements. Yes, there isn&t a single application that currently is capable of doing that. Yes, it makes sense to develop an accounting package for EO.

However, Hexxx is not an accountant, and clearly lacks an understanding of what a balance sheet is, for example. Now that need not be an issue providing he sticks to his skillset - coding - and takes a qualified accountant on to specify the system.

---

Originally by: Varo Jan

---

Quote:

---

NAV reporting must be a part of that, as MD have grown accustom to seeing it in reports.

---

Net asset value is simply one side of the balance sheet. However, the term is often used in MD to denote a more or less arbitrary company valuation. I say arbitrary because there is no standard here for reporting NAV.

Quote:

---

We all know MD/EVE Accounting differs from real life accounting, this is just one of them.

---

Please... don&t go there. Acounting is accounting is accounting. It follows some basic, simple and conservative rules. What passes for accounting here is often an abortion of misunderstood principles inaccurately applied.

Two simple examples. I&ve lost count of the number of people here who confuse cost markup with profit margin. And there are those who don&t understand the difference between cash and profit.

---

Originally by: Varo Jan

---

Quote:

---

Anyway, you've got the criticism thing down...how about working on a solution with the rest of us?

---

Tsk, tsk! Tetchy when criticised? Again, you may have missed my earlier posts - plural.

You&re not going to get a solution in an MD thread. You&ll get a lot of uninformed opinions and some informed which will contradict each other (eg the merits of FIFO vs LIFO, average and standard costing).

I&ve already suggested a solution: recruit a qualified accountant to spec the system for you. Then have the system peer reviewed by other qualified accountants here.

You could also avoid reinventing the wheel by adapting an open source accounting package. Have a look at Source Forge, for example.

---

Originally by: Phoebe Halliwel

---

Originally by: SencneS

---

Everyone needs to think outside their little accounting classes because EVE is not the same as Real life.

Dumbed down version, if I purchase 100mil of something, and sell 50mil worth of something, I still have 50mil worth of something to sell. Regardless of how much that 50mil worth of something or how much it's sold for, I have 50mil worth of cost to sell, so it should be accounted for as 50mil and nothing else.

Where the hangup was, that 50mil of something could be worth 100mil or could be worth 5mil on the market. While a NAV would show either 50mil gain or 45mil loss because that asset is only worth 100mil or 5mil. However the balance sheet is pure, so it must say, I have 50mil of something to sell. At the time of sale of that 50mil for whatever price, the balance sheet is then back to zero.

Like Hexxx, I believe asset value is important enough for overall corporation health.

---

It's not a dumbed down version; it's just dumb and demonstrates your lack of understanding of basic accounting.

3 or 4 different people have explained to you simply that profits are only realised at the point of sale on statutory reports, which the P&L/Balance sheet are. These are governed by global accounting standards. You and Hexx appear to be taking this as a criticism of your point of view, it's not, it's basic accounting. No matter how many times it's explained to you, you apparently aren't going to get it.

If you want to produce share reports that show unrealised profits in stock; fine. Create a separate branch of reports. But don't try to forcibly change/bastardise statutory reporting, as it will invite criticism. Management accounting reports for internal or shareholder use can be created without reference to statutory reports, provided you rationalise and highlight where they are different, and why. You may be quite correct and Eve may require a rather unique set of stock reports. Fair enough, get on with it.

---

Originally by: Mme Pinkerton

---

Edited by: Mme Pinkerton on 27/10/2009 19:43:12
Edited by: Mme Pinkerton on 27/10/2009 19:42:18

Originally by: SencneS

---

The issue that it didn't solve is how do you account for magical items that appear in inventory with no "Cost" associated with them. Things like Mined minerals, Mission Loot, Exploration rewards, and salvage etc.

---

For statuary accounting, you account for them once you have sold them.

I think what you still have not completely realized is that every serious company IRL uses a number of very different accounting schemes in parallel. There's a reason why there are 3 accounting lectures (general statuary accounting, internal & external accounting, accounting for finance/investment) in my university curriculum - and I am doing economics, not business administration.

For external accounting (and that's what an auditor should confirm) the key idea is to create as much comparability between enterprises as possible (i.e. strict standards) while giving equity holders/investors data they can rely on (say, in case of a chapter 7-like insolvency).

In internal accounting (you would generally not base any business decisions on the balance sheet done for the external world) you can do whatever you deem to be useful - but no analyst or investor is ever going to see these balance sheets. In internal accounting you are more concerned with getting a realistic estimate of the state of your business (not a super-conservative one), e.g. one of my professors suggests that you should include the projected value of your customer-base and your human capital ressources in your internal balance sheets - you could ofc never write these in any officially published balance sheet.

I get the feeling that you think that internal accounting practices should be applied to the balance sheets you are going to publish - that's generally not the case (reasons listed above).

---

Originally by: Varo Jan

---

Originally by: Chingyz

---

Originally by: Varo Jan

---

You can&t use one valuation method for one side of the balance sheet and another for the other side!

---

English is not my first language so bear with me on this.

It is not only possible to use different valuation for your income statement and your balance sheet, it is actually in some ways recommended that you do it. Take a look at the IAS, which is what most countries in some way is moving towards when it comes to accounting standards.

You use FIFO, LIFO average or whatever for pricing in your income statemnet and then you use most recent market prices in your balance sheet under your assets. The diffrence is then offset under asset depreciation or appreciation.

---

Read IAS2. The fundamental principle of that accounting standard is: "Inventories(stock) are required to be stated at the lower of cost and net realisable value (NRV). [IAS 2.9]" In practice, that means that stock enters the balance sheet at cost and remains at cost unless seriously adverse conditions occur. You do *not* revalue stock (a current asset & part of your working capital) upwards. Ever.

I suspect you may be confusing current assets with fixed assets, where the latter are depreciated as a matter of course and are very occasionally revalued.

Quote:

---

The difference between the income statement and the balance sheet is that the income statement shows your historic transactions, while the Balance sheet shows the value of your company at the end of your accounting period.

---

I prefer to think of it like this. The P&L or Income statement is one line in the balance sheet. It tells you how well or badly you have done over a period of time. The balance sheet is a snapshot of a company&s financial status/health at a specific point in time.

---

Originally by: Selene D'Celeste

---

Yes, let's apply real world rules and reasoning to accounting in an environment which is distinctly different from the real world. Hexxx, if you're actually going to spend time on this, then go for what's practical. People care about estimated value. So do that. No one is going to give a **** that money is tied up in a Raven as opposed to liquid. If that raven is worth around X, then mark it down as X, and move on.

---

Originally by: Varo Jan

---

Originally by: Selene D'Celeste

---

Yes, let's apply real world rules and reasoning to accounting in an environment which is distinctly different from the real world.

---

Enough already with this smokescreen. If you want to run a successful business long term *anywhere* you need realistic accounting standards. If MD wants to evolve, it needs consistent accounting standards applied to all businesses - your bank-to-be included.

---

Originally by: Varo Jan

---

Originally by: Claire Voyant

---

Originally by: Varo Jan

---

Read IAS2. The fundamental principle of that accounting standard is: "Inventories(stock) are required to be stated at the lower of cost and net realisable value (NRV). [IAS 2.9]" In practice, that means that stock enters the balance sheet at cost and remains at cost unless seriously adverse conditions occur. You do *not* revalue stock (a current asset & part of your working capital) upwards. Ever.

---

While I understand the need for this rule in the real world with real-word products, we are playing an internet space ship game with the possibility of perfectly efficient production and perfectly efficient reprocessing. I for one would like to talk more about why you feel this rule is appropriate in Eve, and less about the way it is done in the real world.

If I am producing shuttles, give me one good reason why I shouldn't value them based upon the current value of the trit they contain, or for that matter, why I shouldn't value a pile of trit at it's current market price.

---

Is coding in Eve any different to the real world? Is marketing in Eve different? Is man-management different? Is researching a market different? No, no, no and no. So what&s with all the angst about accounting?

One of the foundations of accounting is conservatism. That principle doesn&t disappear here in Eve. That&s why you should show your shuttles at cost - not at some hypothetical selling price. In fact, the principle applies very strongly here. Look at the recent massive drop in trit alone. Look at the wild fluctuations in module prices you see on a daily basis.

---

Originally by: Drab Cane

---

Hexx, you're going to have to manually record the 'magic bucket' items.

Record the items at whatever market price you would reasonably pay for them. It will constitute an increase to your assets, and an increase to your revenue. Show the revenue as "Revenue from . . ." whatever the source was (mining, salvage, loot) on the income statement.

---

Originally by: Drab Cane

---

Along the same vein as Wyehr's question, Hexxx, are you looking at building a system for your operations only, or are you looking at a system that could be rolled out for other, interested players?

---

Originally by: Drab Cane

---

Again, regarding recording items that have not been obtained through the EVE market (and thus through the API):

Would it be safe to say that an NAV worksheet is pretty much the standard financial statement for EVE? I would think that assets are relatively easy for an auditor to tie out with the NAV, and any liabilities would just have to be confirmed.

My point is, your balance sheet and income statement could be used as internal reports, and the NAV would be used for external purposes (auditors and investors).

You could reflect whatever asset value seems reasonable for your internal accounting, and reflect market value on your NAV. As long as your accounting system correctly tracks how many assets (inventory, etc.) you have, and how much cash you have in your wallet(s), producing both the internal and external reports should be straightforward.

---

Originally by: Drab Cane

---

It sounds like you do want to have an auditor confirm not just the value of the operation, but its profits and expenses as well. I don't think you'll find a shortcut, you'll have to go 'all in'. The API simply does not track enough information to properly track most asset transactions, and you will need to generate your own records that fill the gaps (as I believe someone suggested above already).

Why is grouping alts that much of a challenge? As far as I know, all transaction/journal/asset IDs are system-wide. Track individual alts as their own 'department'. Add a 'department' field to your import tables, and fill it with either the ID of the character you're importing from, or the number of the corp wallet.

You should be able to code the 'department' field in such a way that you can automatically handle 'inter-departmental' transactions (at least, that's the theory).

---