The Erinyes of P&L

17/05/2024

i adore oldhead university professors who'll just upload all their lectures on their 1.0-web-ass site. truly they are my fellow and the light of heaven falls upon them.

i've decided that i'm going to tackle Aswath Damodaran's valuation and coporate finance lectures, which are all up on his personal site, take notes and study the material. i'm enjoying the process a lot already, and one day i'll have to face the fact that i just fundamentally find it easier to study certain topics that lend themselves to this style of progression than something more hands-on like learning to draw, no matter how unshakeable a vague desire to explore some kind of artistic outlet.

it tickles my brain that from the very beginning - i'm going through his Primer on Financial Statements - i've had to slow down and make sure i get the edge-cases and avoid future pitfalls. right now in specific i'm looking at frameworks to recognise revenues on the income statement.

revenue overall is simply the total income generated by the sale of goods and services, before you start taking costs into account. you sold 42 million USD worth of bricks? your revenue is 42 million USD, no matter whether on the process of selling said bricks you incurred a cost of 10 USD or 41 million USD (or, worringly, a number higher than the revenue!). revenues, plural, refer to individual income streams over a set period of time, usually a financial quarter. you've got revenues from your brick-selling division, revenues from the brick-making division, revenues from coke-dealing, etc etc; they're all reflected on the income/P&L statement.

now, there's a surprising amount of nuance about how you're supposed to (well, really how US companies are supposed to under Generally Accepted Accounting Principles) recognise revenues in your income statement. a lot of times you'll sell a good or service in one period, but not receive payment for that sale until another period. a question immediately arises as to what you're supposed to do here; do you write down that you sold X USD worth of bricks this quarter when the sale was made, or write it down next quarter when X USD actually appear in the company bank account? US GAAP is fairly straightforward here: the former. you recognise the revenues in the period the sale was performed, regardless of when the money will actually come through. this is called accrual accounting, and one of its principal pillars is the "matching principle", which states that expenses related to the creation of revenues are to be declared together and in the same period, also regardless of when payment for said costs is actually performed. you sell X USD worth of goods and incur Y USD costs, X and Y are declared together, when money actually changes hand is irrelevant.

HOWEVER. however. in their finite but modestly sized wisdom the Financial Accounting Standards Board acknowledges that certain circumstances, certain industries, companies of certain sizes, would not be properly served by accrual accounting. one of the alternatives is cash accounting, which is the most straightforward, and the one that feels most natural: you declare revenue when you get paid, you declare expenses when you pay out. note that one consequence of this simplification is that revenue and expenses are delinked! you're no longer required to match revenues to the expenses it took to create them, the only criteria is the "when" of payments.

a third method, the installment method, is allowed when there is "considerable uncertainty about the capacity of a buyer to pay for goods delivered/services rendered", which i find inherently hilarious. you'd assume that counterparty risk is just kinda, a thing you have to deal with in business? but apparently if you make a particularly compelling case about the skeeviness of your business partners (the business partners you chose!) you get to use a more lenient accounting treatment for that specific income stream.

the installment method is a weird hybrid of accrual and cash-based accounting, and it took me a bit to wrap my head around the nuances, which is what prompted this post. under it, the company is allowed to recognise revenues when it actually collects portions of the money owed - so far this is just like cash accounting, you recognise it when you've been actually paid - but expenses are only recognised when you collect the revenue, and in the same proportion of the total revenue paid out so far, regardless of when payment actually occurred!

this one threw me for a bit when i read it, it was really hard to parse what exactly is different here. an example helps a lot.


you run a brick selling company. let's look at two quarters of this company's existence, Q1 and Q2. you sell 10k USD worth of bricks to some other company on Q1, and it costs you 2k USD to do this.

you recognise 10k USD worth of revenue and 2k USD worth of matching expenses on Q1. you're done. you recognise 2k USD worth of expenses on Q1. you recognise the 10k USD when you're actually paid 10k USD or a portion thereof; if that's in Q1, in Q1, if in Q2, Q2, etc. you're going to be paid in installments. in Q2 20% of the 10k owed come in. on the revenue side you recognise 2k USD. on the expenses side you recognise 20% of the total 2k USD expense, so 400 USD.


i have no idea if that made it any clearer, i hope it did. the best and clearest summary i can give is that the installment method does cash-based accounting for the revenue but only recognises expenses once payment has come in, regardless of when the expenses actually happened.

all will agree that it is obvious accrual is Megaera, cash is Alecto, and installment is Tisiphone.