Live data from Hacker News

Accounting For Developers, Part I

moderntreasury.com

161–170 of 193 posts

Re: Accounting For Developers, Part I

#161

Earlier quoted context omitted.

What you're describing is accrual accounting (accounts payable/receivable). It is one method of bookkeeping, but a lot of other businesses tend to use cash (which deals in absolutes, you spent 5, you earned 5, etc).

You can model the data in such a way that the recorded transactions can be reported on in either accrual or cash basis.

Not sure what you mean, as far as I know the government requires businesses to pick one form and stick to it. Unless you're building accounting software you'd have no need to support both ways.

Re: Accounting For Developers, Part I

#162
I've implemented tens of accounting systems, always multi-currency and usually multi-lingual. Originally in RDBMS, but in the last decade generally with triggers in SQLite. The most complicated one I've done was Kraken (~2011) which needed arbitrary precision support for unknown future crypto asset types.

Opine: (1) Accounting as a profession is being automated away as governments create APIs to facilitate report submission and SCM/ERP/payroll become automated. Not too soon. (2) Yes, IMHO absolutely the debit/credit account terminology needs to die. It's backward and a source of confusion for the non-indoctrinated. Use negative numbers and present formatting for antiquarians where required. (3) As a student of ancient history, falsely ascribing off-handed western-inventors to things is so 19th century colonialist. Double entry is just an overly-lauded stage in the development of accounting anyway, not the endgame. Ancient societies got by just fine tying knots in cords (ancient China, Maya, Polynesia, etc.) and many ledgers run fine without double entry now. It's primitive compared to what's available in computer science today. (4) Distributed transaction systems are an algorithmic problem, not an excuse for manual documentation. Let's give away autonomous implementations for free, make GAAP about reporting, standardize account and transaction identification and innovate on process.

New systems recommendation:

(1) For account identification, use IIBAN which provides IBAN-compatible account identification and checksums and is an open system @ https://github.com/globalcitizen/iiban

(2) For all accounting, use UTC.

(3) For transaction identification, use UTC second of origination (UTCSO) + account of interest (AOI; eg. IIBAN) + intra-second transaction identifier (ISTI).

Free thoughts on forward-looking accounting systems @ https://raw.githubusercontent.com/globalcitizen/ifex-protoco...

Re: Accounting For Developers, Part I

#163

Earlier quoted context omitted.

> "debit" and "credit" and > think they have to do with > "owing" or "being owed" money. I think of it as 'owing' (liability) or 'owning' (asset). When you credit an account, you either increase what you 'owe' on that account OR decrease what you 'own' on that account. Examples: - bank credits a customer account => bank owes more to its customers - company credits income account => company owes more to its shareholde…

That makes sense to me in terms of assets and liabilities, but when I read https://beancount.github.io/docs/the_double_entry_counting_m... and it described income as being negative and expense as being positive, it broke my brain a little bit.

Very simple explanation: Entries in double-entry accounting always need to balance - you need two.

So if somebody gives you $100 in cash, you book that as $100 in your "cash" asset. But... the books must balance! And so, you need to book -$100 on the "income" side, because that's where the cash comes from.

If you're not happy with "because it needs to follow the rules" alone, replace "income" with "other people's money". For you to get cash, somebody else needs to give up cash.

The reason you differentiate between asset/liability and income/expense accounts is that you can't really fully balance the latter two. You don't know all the details happening to "other people's money". You know everything happening to your assets and liabilities.

As a result, income/expense are accounted over time ("I made $x/year") while assets liabilities are a value ("I have $357 in my cash drawer") - for the former two, all you know is the delta over time you cause.

Re: Accounting For Developers, Part I

#164
post #136

Earlier quoted context omitted.

This is going to be quick, dirty, and simplistic. I've explained deeper in a different comment. But this should help. Things to keep in mind... The accounting equation: Assets = Shareholder Equity + Liabilities. This expresses what we own (assets) and who has a claim over what we own (shareholders, creditors). Shareholder's equity can be expanded as: Retained Earnings + (Revenue - Expenses); retained earnings is reve…

>When you sell the inventory you have a multi-part transaction. Inventory movement: Credit the Inventory Account (asset) by $1 and Debit the Costs of Goods Sold Account (Expense) by $1. You no longer have the inventory. The Sale part: Debit the Cash Account (asset) by $2 and Credit the Sales Account (Revenue) by $2. You have received a new $2. So that answers part of question 2, but not entirely. And it doesn't addre…

Unfortunately, I'm doing a half-assed reading job, so giving half-assed answers :-). My apologies.

For question 2, the whole thing is actually in my answer. It's in the Equity side of the equation. Revenue - Expenses = Profit. The inventory and asset side doesn't really have anything to do with profits per se; sure those profits may be cash assets in the cash accounts... but so might cash from a loan or similar non-revenue source. So the income statement is based on those bookings. The cash, the inventory, etc. on the Asset side of the equation don't really have much to say about profit. It's just stuff you own. The reason it's in the breakout of the Shareholder Equity side of the equation is because it's the shareholders who are exposed to profit or loss; the concept of profit/loss just doesn't need to appear elsewhere. Often times you'll hear accounts talk about "income statement accounts" and "balance sheet accounts". Revenue and Expense accounts are the "income statement accounts". At the end of a fiscal year, the income statement accounts, which state the profit or loss, are basically netted out and booked as a "Retained Earnings" entry. The "balance sheet accounts" including asset accounts like cash and inventory valuation or liabilities, on the other hand carry their values year over year.

To your inventory valuation question (you may ultimately be sorry you asked :-) ). Inventory valuation accounting is more complicated than it first appears and how it happens can best be summed up as: it depends on a number of factors. The nature of the business, the preferences of the accounting management team, etc. Sometimes there can be multiple inventory valuation methodologies in operation at once depending on who is consuming the information being produced or the specific inventory being valued. Note that with all methods, the basics from my first comment will still apply: these different methods are primarily aimed at how to arrive at a unit cost

First, a couple disclaimers. I'm not a CPA/Accountant/etc. I am principally a technologist and some of what I'm going to be giving you is based on the understanding I've developed for my own purposes of the issues rather than something more textbook. I do have around 30 years of experience which consists of a combination of management roles within companies with significant and complex inventory management accounting (think chain retailers), ERP implementation consulting into retail, distribution, and manufacturing companies including working with finance teams for accounting implementation, designing a Retail Method stock ledger for an ERP system, and finally redesigning the costing mechanisms of a manufacturing-centric ERP system (as well as doing the development work) along with a fair amount of research into these questions. None of that promises that I know what I'm talking about, but at least I've had to think about the kinds of questions you are asking at some depth.

Inventory valuation. There are a number of different approaches as others now in this thread have mentioned. First In-First Out, Last In-First Out, Weighted Average Costing (more on this in a bit), Standard Costing, Actual Costing, Job Costing, and Retail Method, to name a few. These methods have different histories and traditions and some are more prevalent in certain industries than others.

Knowing which to use involves knowing which goals you're pursuing. First there's a division at large in accounting which needs to be understood. There are two kinds of accounting of interest here: Financial Accounting and Management Accounting. Financial Accounting is about producing financial statements for investors, banks, etc. and for tax reporting (a whole other can of worms I will mercifully/largely avoid here). Then there's Management Accounting. Management Accounting is concerned with internal nuanced understanding the operations of the business at large. These goals don't always see the world the same way and will have different demands of accounting. You'll see terms like GAAP ("Generally Accepted Accounting Principles", the U.S. standard for Financial Reporting) and IFRS ("International Financial Reporting Standards", same as GAAP for much of the rest of the world). These are targeted at investor financial statements and so fall into the Financial Accounting category.

Costing methods associated with Financial Accounting (GAAP/IFRS) are Weighted Average Costing (conditional for tax purposes), FIFO, LIFO (only under GAAP, not IFRS, allowed by the IRS under certain conditions), Job Costing (conditional), Actual Costing, and I believe Retail Method is also accepted in GAAP/IFRS, but not tax (I could be wrong), but I really see it as a Management Accounting method. Management Accounting methods include Standard Costing and Retail Method. Note that for the Retail Method especially and Standard Costing to a lesser degree, their usage has changed over time from use in Financial Accounting to be more Management Accounting focused. Also know that many applications implementing costing conflate these purposes, especially on the lower end of the market: they rely on expertise in the accounting area to produce correct reports or laxity by investors and taxing authorities to care. Bigger systems tend to get it and implement things right (if annoyingly so).

Of all of these, for Financial Accounting, the most popular would be a flavor of weighted average costing or FIFO. Others mentioned LIFO as being more accepted, but that's backwards: it's FIFO. LIFO is not acceptable under IFRS and really only the IRS acceptance (and interestingly the tax advantages that can show up with LIFO) that keep it alive at all.

-- Weighted Average Costing. As you've suggested, when you have inventory where individual units stocked are fungible with all other units of the same item (I call this "Unit General Costing"), you can simply average the receipts of inventory with that already on hand and arrive at an average cost. There are different flavors of this basic approach. What I'll call "perpetual average costing" involves immediate updates to the average unit cost whenever new units are received into inventory; simply put: (new receipt value + existing inventory value) / (new receipt quantity + existing on hand quantity) = Current Unit Cost for things like sales transactions. Note that transactions like sales shipments don't change the current unit cost, only receipts of new inventory such as new purchases. There's also what I call "periodic average cost". In periodic average cost methods, the cost is calculated at the beginning of some period of time: a day, a week, maybe even a fiscal month. The same cost calculated for that period is used in all transactions that issue inventory (e.g. sales order shipments), when the period rolls over to the next, the current inventory with the actual receipts of the period are then used to calculate a new average cost for the new period.

-- First In/First Out. The basic mechanics of this costing method is pretty evident from the name. You keep a log of received inventory quantities and the costs they were obtained at. As you issue (ship) units you relieve the inventory at unit cost with the oldest inventory going first using the costs from the log. Sure you might not be shipping the specific units in FIFO order, but who cares? If the inventory is truly in that "unit general" accounting category... it doesn't matter.

Naturally there are conditions that crop up that can foil things. For example, there are cases where taking your on-hand inventory quantities into negative territory is valid; also, there are companies that have legitimate reasons for backdating transactions. Think what that does in either of the Average Costing or FIFO costing cases :-). And we haven't even discussed loading the costs that you find out about later for things like capitalized freight, etc. There are ways of dealing with these things, but the common-case gist of it all I think is captured above. (plus I'm a couple or four beers in now and should probably stop :-) ).

I don't know if that provides clarity, but at least it should give you some sense of the size of the question you're asking.

Re: Accounting For Developers, Part I

#165

Sometimes non-accounting people get hung-up on the words "debit" and "credit" and think they have to do with "owing" or "being owed" money. The effect of a debit or credit on the business depends on the accounts in the transaction and debit and credit don't have anything to do with the "direction" of a flow of money. My 100-level accounting instructor summarized it as: "A debit is the entry in the left column, and a…

You just look silly trying to build financial software without understanding and implementing double-entry or ledgers. You have to know when to employ debit and credit nomenclature and be able to easily explain the reactions in the system...or you look silly. Sort of like when accountants start talking about databases and APIs without proper training. I have had to train developers on the simple concept of a ledger,…

Why don’t they like currency symbols?

Re: Accounting For Developers, Part I

#166
post #130

Earlier quoted context omitted.

I think you can expand this explanation with database terminology. In modern RDBMS, you could have naive implementation with two account's balance, and increment one decrement the other. But without transactions it just isn't safe, its better to have one row in a table with a debit and credit. Now if you're doing accounts by hand you really need that single line transaction record.

> its better to have one row in a table with a debit and credit. No. Some transactions have 3 lines, eg: two debits and one credit. Some examples: - Split payment at a shop, $100 item bought with $70 cheque and $30 cash would be credit sales $100 debit cash $30 debit bank $70 Now if you introduce sales tax or VAT/GST, its more complicated. Say the $100 item is actually $90 + $10 VAT, then entries goes: credit sales $…

I saw some systems that used single line, even in these cases. It had an ephemeral/transitory account to help on this. And to map it together, all these entries would be related to a single transaction. It seemed a nice solution for me.

Re: Accounting For Developers, Part I

#167
post #27

Any time the idea of double entry bookkeeping comes up there is nothing but unanimous advocacy for it. This thread echoes the same sentiment where there's several comments about the importance of double entry. And yet like all previous endorsements I've heard, I've not been able to take away why it is so important. The reasons are always around error tracking, tracing source of funds, standing the test of time etc. a…

Let’s take a simple example I buy a plane ticket on January 1st with my credit card for $100 for a flight on March 15th. I paid my credit card bill on February 15th.

I simplistic view would be I spent $100 on January 1st.

Using double entry accounting I can track what is actually happening in that transaction,

1. I buy the ticket w/credit card (CC lent me $100 for an asset (plane ticket) = (cash +100, liabilities +100, assets +100, cash -100) 2. I pay my credit card bill (cash -100, liabilities -100) 3. I take my flight (+100 expense, -100 net worth)

Steps one and two I have yet to incur an expense, cash is changing hands and the composition of my balance sheet is changing, step three I actually incur an expense. That’s the beauty.

Re: Accounting For Developers, Part I

#168

Earlier quoted context omitted.

> Lets say you sell a service to someone, a year of service for $100. This sounds simple, debit cash for $100 and credit sales revenue for $100 I'm confused, this seems like you would credit both cash and sales revenue $100... since you'd have received $100 from whomever bought your service, so youd have $100 more cash, and for tax accounting, you'd have sold $100 worth of stuff as well.

In the double-entry model, things follow the accounting identity: Assets = Liabilities + Equity and its more dynamic corollary since Equity = Capital + Income - Expenses, simplified to keep everything positive: Assets + Expenses = Liabilities + Equity + Income Assets and Expenses are considered to have a debit balance and the other three have a credit balance. Debit represents money "owed to" the business and credit…

91.67

Re: Accounting For Developers, Part I

#169

Earlier quoted context omitted.

You can model the data in such a way that the recorded transactions can be reported on in either accrual or cash basis.

Not sure what you mean, as far as I know the government requires businesses to pick one form and stick to it. Unless you're building accounting software you'd have no need to support both ways.

It’s common for US businesses to file taxes on cash basis but use accrual for managerial accounting.

Re: Accounting For Developers, Part I

#170

I think the figure / chart in "Effect on balance by account type" is wrong / flipped. It says that debits decrease debit normal account balance which doesn't match the text description or subsequent examples.

Author here. This is helpful feedback, we could have perhaps taken more time before jumping in on the Modern Bagelry example. A common misconception is that one account needs to increase while the other needs to decrease. But what we are actually showing that they can both increase or decrease in tandem, depending on the debit and credit entries in the transaction and the direction of the accounts. In the first trans…

The main issue was that at the time the "Effect on balance by account type" figure was reversed / incorrect, and so the example was just not making sense. Reading on further and again I realized it was not the example but that figure that was wrong. I see that you fixed that now. Thanks.
Post reply on HN