Accounting for a firm's inventory of securities is a topic extremely important to many groups, including the firm's traders, managers, and investors, as well as external groups such as regulators, auditors, and taxing authorities. Combined with trading profit and loss (both realized and unrealized), the topic is often perceived as difficult to understand and harder to implement.

We will have quite a bit to say about these topics, but fortunately they are relatively straightforward within the Framework we've been discussing. If you have any questions on these topics, we encourage you to contact us. We'll be happy to respond quickly and thoroughly.

Inventory accounting is common to many industries, of course, and the main issue is also common to all: determining cost.

An Example

We start with an example. Our firm begins the day with no inventory in security XYZ. In the morning we buy 100 shares for $100. We then sell 50 shares for $54. Later in the day we buy another 100, this time for $112. Simply adding them up, at the end of the day we net to 150 shares and $158.

			Buys				Sells
Nbr	Activity		Quant	Prc	Money		Quant	Prc	Money
1.	Buy		100	$1.00	100.00
2.		Sell					50	$1.08	54.00
3.	Buy		100	$1.12	112.00
	Total		200	$1.06	212.00		50	$1.08	54.00

We can ask a number of questions about this activity:

• What was the cost of the securities sold?
• How much did we make on the sale (i.e., trading P&L)? By definition, this will be the sales proceeds ($54) less the cost of securities sold.
• What is the cost of the remaining inventory, the 150 shares?
• How much does the ending inventory cost differ from it's unadjusted value ($158)?

Date Basis

We need to be clear about the date basis we're using for inventory. As noted in Positions and Balances, there are a number of date bases used in securities accounting. Firm inventory is generally kept on a trade date basis (technically, it's the trade-effective (TE) date basis).

¶ 7.18 of [AICPABDSec06] discusses the reasons for using trade date basis. In brief, it is because a contract exists on trade date and the "risks, benefits, and economic potentials are created and conveyed" at that time. Securities prices are also generally quoted on the basis of regular-way settlement, which is another way of saying they're on a trade date basis. See Dividends for how it appears in the ex-date context.

Cost

All the questions from the example are based on determining cost, either of the securities sold or of the ending inventory. There are a number of possible values for cost, and all are valid. Looking at the first question above, if the firm were selling used cars we would use whatever we paid for the particular car being sold. This is not our situation, of course, so we consider other methods. The following table explores the implications of each of three common methods for assigning a cost to the securities we sold.

			Cost of Goods Exchanged							Ending Inventory at Cost
Method	Description		Price	Value		Profit/Loss				Price	Value	Diff
FIFO	First-in, first-out		$1.00	50			4			$1.08	162	4
LIFO	Last-in, first-out		$1.12	56			2-			$1.04	156	2-
Average	Average cost		$1.06	53			1			$1.06	159	1

There are a lot of numbers in this table. This is one case, however, where things are much simpler than they seem. We note the following:

• The sum of the Cost of Goods Exchanged (cost of goods sold, in our example) and the value of the Ending Inventory is constant, $212, regardless of the method. We would expect this. We had $212 in inventory available for sale, and it had to go somewhere: it was either sold or remains in inventory.
• If you set the value of any one number on a row in the table, all the other values on the row are determined. This follows from the above.
  • Setting the value of Ending Inventory, for example, fixes Cost of Goods Exchanged (the two sum to $212). Or, you could go the other way and set Cost of Goods Exchanged and thus determine the Ending Inventory.
  • If you know Cost of Goods Exchanged, you know your profit or loss on the sale. And vice versa.
  • The profit or loss on the sale is the same as the adjustment you have to make to inventory to get it from the posted balance to the cost basis. When the sale is booked, of course, inventory is reduced by the sales price, not the average cost. To get inventory back to weighted average, you have to put back in the difference.
  • Setting the price of Ending Inventory clearly gives you its value (the ending position of 150 shares is fixed). The same applies to the price of the securities sold and their value. And vice versa (from value to price).
• These relations hold regardless of the cost method you choose.
• This means that the method for determining Cost of Goods Exchanged (e.g., selecting LIFO) implies a corresponding method for determining the cost of Ending Inventory.
• For completeness, we'll mention that if we had a position at the start of the day, we would add its balance (at cost) into the inventory available for sale.

More formally, we start with the following observation, which in our example resulted in 150 shares and $158. (In all the equations the terms for which we have a value available in the system before adjusting the cost figures are presented like this.) As you might expect from the appearance of all the terms, this first equation is really a tautology, a definition of the term on the right.

1.	Beginning Balance (at cost) + Purchase - Sales = Ending Balance (not at cost)

The first bullet point we made above (about the constancy of the $212) is a rearrangement of a fundamental inventory accounting relationship. This relationship has a name: the "inventory equation". (See the entry in [AcctLangBus05].)

2.	Beginning Balance (at cost) + Purchases - Cost of Goods Exchanged = Ending Balance (at cost)

We also have this definition:

3.	Profit/loss = Sales - Cost of Goods Exchanged

We can combine these three equations to derive:

4.	Ending Balance (at cost) = Ending Balance (not at cost) + Profit/Loss

Reviewing these equations we find four terms for which values are available before anything is done to adjust for cost:

• Beginning Balance (at cost)
• Purchases
• Sales
• Ending Balance (not at cost)

This leaves us with three terms for which we have to determine values:

• Cost of Goods Exchanged
• Profit/loss
• Ending Balance (at cost)

We saw from our table of methods that there are many possible values for these three terms. We also mentioned that fixing one will fix the others. We see this in equations 2, 3, and 4, as they relate the three terms on a pair-wise basis. In equation 4, for instance, fixing Ending Balance (at cost) fixes Profit/Loss, and vice versa.

Accounting for Cost

There is no regulatory requirement as to the method for determining inventory cost. The FASB gives a few general choices: average cost, first-in first-out, last-in first-out, and "etc.". ¶ 21.b of [FASBStmt115] gives specific identification (as in the used car example), average cost, and "other".

The most common method encountered, and the only one we'll consider going forward, is average cost (this is usually called "weighted average cost"). There are a number of reasons for this:

• Average cost is based on the idea that there is no definite relationship between the specific items bought and those sold (LIFO and FIFO do). This certainly applies to securities, where the shares/bonds are completely interchangeable.
• Average cost assigns the same value to the items sold as to those remaining in inventory. This seems reasonable for securities.
• It's easy to implement, much easier than LIFO or FIFO. Both LIFO and FIFO require you to maintain a history of layers of inventory as a means of calculating cost. This is a complex effort, without any apparent benefits in this instance.

The following relationships hold only for the average cost method. The earlier equations (in terms of numeric sequence: 1 - 6; 5 and 6 are still to be introduced) apply regardless of method.

7.	Average Cost = (Beginning Balance (at cost) + Purchases) / (Beginning Quantity + Quantity purchased)
8.	Ending Balance (at cost) = Ending Quantity * Average Cost
9.	Cost of Goods Exchanged = Sales Quantity * Average Cost

Inventory of securities is different from most other inventory situations for a number of reasons. First, we are dealing only with finished goods. There are no raw materials or production processes. What we buy is exactly what we sell. Similarly, our vendors are our customers. Our accounts receivable system is also our accounts payable system.

Another difference is that we don't have to sell in order to have a trading profit or loss. Because we can start our trading by selling a security we don't have (we will have to borrow it to make delivery, of course), we can easily have a profit or loss on buying a security, not just selling. If we sell 100 shares for $110 and then buy the same number of shares the next day for $100, we have made $10. This is why we used the term Cost of Goods Exchanged rather than Cost of Goods Sold earlier. At this point we are focusing on long positions, for simplicity. The general long/short situation is addressed in Revised Equations.

These factors lead to differences in the accounting. Firm Buys are the same, but Sells are handled differently. The following table gives the accounting for the example transactions we've been discussing, as handled in other industries and then in the securities industry.

Other Industries			The Securities Industry
The firm buys:
Inventory	$100		Inventory - Long	$100
Payable	$100		Payable	$100
Inventory	$112		Inventory - Long	$112
Payable	$112		Payable	$112
The firm sell:
Receivable	$54		Receivable	$54
Sales	$54		Inventory - Short	$54
End-of-day (described below):
Cost of Goods Sold	$53		Inventory - Long	$1
Inventory	$53		Realized P&L	$1

We see that in other industries there are accounts in the chart of accounts for Sales and Cost of Goods Sold; the difference is the profit or loss. In the securities industry, Sells are booked directly against inventory. There are no Sales or Cost of Goods Sold accounts. What the securities industry chart of accounts does have, however, is a Realized Profit and Loss account (PLR) in the chart of accounts (this is the usual term for what we have been calling Profit/Loss to this point). In other industries profit/loss is a report-time value created from Sales and Cost of Goods Sold.

These points actually make the realized profit and loss algorithm quite simple (given a suitable starting framework, of course), simpler than other inventory applications.

To complete the accounting for our example, we would have to book the following journal entry:

This gets inventory to the correct cost basis as well as recognizing our profit.

This is simply a realization of equation 4 above. Calculating realized P&L is exactly the same as adjusting ending inventory to cost. And vice versa, of course.

We point out that all references to "journal entries" on this page are referring to explicit register entries stored in our Data Structures. These are not simply logical guidelines for updating a figure in a trader position record. Physically storing such entries is very important to the quality of the system: it provides transparency, directly supports auditability, and insures a consistent approach to system updates.

Calculating Ending Inventory at Cost
    aka, Calculating Realized Profit & Loss

There are a number of approaches to calculating the Realized P&L component of trading profit and loss. We'll focus on the one most natural within the Framework and then discuss the common alternatives later.

A limitation of most discussions of trading p&l is that they do not cover all the events that can affect it. The usual focus is on buying and selling, naturally, but there is usually no mention of situations such as a bond maturing (this will affect realized P&L). Events such as cancellations, corrections, and as-of trades are also often not covered.

Our approach focuses on equation 4. We calculate the Ending Inventory (at cost), which then determines Realized P&L.

This is where use of the average cost method makes our life very simple. The average cost method assigns the same cost to items exchanged as to those left in inventory, so there is only one unit cost to be determined (equation 7). And that is simple. All we need to do is determine the long and short inventory available. That is determined by the transactions that hit the BUP (for Buys) and SEP (for Sells) principal accounts. Absolutely nothing else enters into the considerations.

We have the following general classes of business events that will have distributions affecting the principal accounts:

Class	Description
Trades	Buys and Sells.
Exchanges	These have distributions similar to (and sometimes identical to) trades. They depend on the type of security: Debt instruments at maturity. Called securities. Conversions. Exercises and assignments of options.
Modifications	Cancellations and corrections. These are housekeeping functions for the above classes.
Journal entries	These can be for any reason. The Framework is robust enough to handle all required events, but we include this to cover cases where the implementing firm wants to provide a journal entry capability.

The first two classes can be found in the Knowledge Base's Register Type; just scan for "BUP" and "SEP". If your application has other events that affect inventory, they would be set up there as well.

We present the algorithm first in English and then in the language of the Framework.

The Algorithm In English

Getting the ending inventory valued at weighted average cost follows the steps given below. All reference to "day" should be understood in a trade-effective date sense: the greater of trade date and effective date. This will pick up all as-of trades, as well as as-of cancellations and corrections.

1. Start with the day's beginning inventory at cost.

   We will see later that inventory is actually stored at fair value rather than cost. The amount by which we go from inventory at cost to inventory at fair value is stored in the account Unrealized P&L (PLU). We have to back this out of the beginning principal balance to get to the cost value.

   The opening position and balance (at cost) are treated exactly like a trade for that quantity and money. In a weighted average cost inventory model there is no difference in the handling of trades and the opening inventory.

2. Determine the amount of long inventory available, at cost.

   This is done by adding the beginning inventory (if long) and the day's Buys, less cancellations and corrections of Buys and redemptions of long positions. (In our example, this results in 200 shares and $212; average cost is then calculated to be $1.06. See equation 7.)

3. Determine the amount of short inventory available, at cost.

   This is done by adding the beginning inventory (if short) and the day's Sells, less cancellations and corrections of Sells and redemptions of short positions. (In our example, this is 50 shares and $54; average cost is $1.08.)

4. If the ending position (150 shares) is long, set the ending average cost to the average cost of the long inventory available ($1.06 in our example); otherwise set it to the average cost of the short inventory available.

   Multiply the ending position by the ending average cost to get the ending inventory at cost (150 * $1.06 = $159). Compare this to the net inventory ($158, which is $212 - $54). Generate a journal entry to take inventory from net to cost ($159 - $158 = $1). The other side of the journal entry is Realized P&L (a $1 credit, or profit, in our example).

One variation applies to primary broker/dealers in Treasuries. In step A, on the first day of the month the unrealized P&L is not backed out. This results in the end-of-month unrealized P&L becoming part of the cost basis in the next month. This is referred to as "realizing the unrealized".

The Algorithm within the Framework

Expressing the algorithm in terms of the Framework is more concise and easier than the version above. The reason is that we only have to look at account codes in the Knowledge Base: BUP and SEP. We don't care if a reversal record came from a cancellation or a correction. We don't care if a position is liquidated by a sale, a bond maturing, or an option being exercised. The only thing that's important is the effect (debit or credit) on the inventory accounts. The table given earlier is useful to illustrate what we're considering, but in the final analysis it's only a guide to the underlying approach.

The Framework approach also means that any new transactions set up in the Knowledge Base, or journal entries where the user enters a distribution explicitly, will be handled correctly. There is no additional programming required. Those new transactions can also be cancelled and corrected without any additional programming. All we are concerned with are debits and credits to inventory.

We will be working in trial balance format, so we will normally just be talking about adding values. It also means we will begin seeing a lot of minus signs in the example data, primarily on the short side. These are simply credits, the normal side for a short. All of the position and balance records we access will have Book Type of PRIM.

The results of the processing are summarized in Final Data Structures below. It may be helpful to refer to that section while going through the algorithm.

1. Start with the day's beginning balance in principal at cost.

   Get the prior day's value from the TE-M BUP row (or SEP row; there will be only one or the other) in the PandB entity for the trading account and security. Add the value from the TE-M PLU row to it (because we're in trial balance format, this is the same as "backing it out"). This is inventory at cost. It may be long or short.

   Get the corresponding TE-P entry to obtain the opening position (i.e., the prior day's closing balance).

   As mentioned above, the opening position and balance are treated exactly the same as a trade.

2. Determine the amount of long inventory available, at cost.

   This is done by adding the beginning inventory (if long) and the day's register distributions that posted to BUP. (In our example, this results in 200 shares and $212; average cost is $1.06.)

   Just to reiterate, a normal Buy will have a debit to BUP. A cancel will be a credit (to BUP, not SEP), so adding the cancellation to the total will decrease the long inventory. Similarly, a long position being converted would be a credit to BUP. In trial balance format all the math works correctly and automatically.

3. Determine the amount of short inventory available, at cost.

   This is done by adding the beginning inventory (if short) and the day's register distributions that posted to SEP. (In our example, this is -50 shares and -$54; average cost is $1.08.)

4. Obtain the ending position from the TE-P row (150 long in our example). If this is positive (long), set the ending average cost to the average cost of the long inventory available ($1.06); otherwise set it to the average cost of the short inventory available. (Average cost is not affected by trial balance format; it is always positive.)

   Multiply the ending position by the ending average cost to determine the ending inventory at cost (150 * $1.06 = $159). Subtract the ending inventory (not at cost) from the desired ending inventory (at cost) ($1 = $159 - $158). This is the posting to BUP (if ending long) or SEP (ending short). The other side of the journal entry is Realized P&L (a $1 credit, or profit, in our example).

The differences between the English version and the Framework version are:

• Because the Framework stores amounts in trial balance format you don't have to worry about adding vs. subtracting vs. netting vs. backing out. You just add (the one exception is the subtraction to get the net inventory change in the final step).
• You don't care about any attributes such as Register Type (e.g., a Buy vs. a Sell) or if something is a cancellation or a correction. You look only at the distribution.

This takes ending inventory to the average cost (and Realized P&L to the correct value).

Fair Value

¶7.02 of [AICPABDSec06] states:

A broker-dealer accounts for inventory and derivative positions (such as futures, forwards, swaps, and options) at fair value.

"Fair value" is a very large topic. The AICPA reference cited above is probably the best current over-all discussion available. While we won't go into fair value in great detail, we will give an overview of the major factors and where additional information can be found.

Fair value is based on two primary considerations:

Consideration	Description
Intent	[FASBStmt115] uses the firm's intent as the first consideration. It defines three categories (see p. 4): held-to-maturity securities, trading securities, and available-for-sale securities.
Determination	[FASBStmt157] addresses the definition of fair value, the methods used to measure it, and disclosure requirements. It identifies a number of approaches, including market, income, and cost approaches. It also establishes a hierarchy of inputs to the determination of fair value.

Regardless of the method, we have (this and the following equation apply to all inventory valuation methods, not just average cost):

5.	Ending Balance (at fair value) = Ending Quantity * Fair Value Price

For our application, fair value is market price because the firm is engaged in the trading of securities, and the securities have a highly active market.

For accounting purposes we have the following. Note that at this point, because of the realized P&L algorithm, we already have Ending Balance (at cost).

6.	Ending Balance (at fair value) = Ending Balance (at cost) + Unrealized Profit/Loss

Fortunately, marking the position to market is simple. It parallels the last step for setting the position to average cost. We will assume the market price at the end of the day is $1.04. The algorithm then is:

Obtain the ending position from the TE-P row (150 long in our example). Multiply the ending position by the market price to determine the ending inventory at market (150 * $1.04 = $156). Subtract the ending inventory at cost from the desired ending inventory at market (-$3 = $156 - $159). This is the posting to BUP (if ending long) or SEP (ending short). The other side of the journal entry is Unrealized P&L (PLU) (a $3 debit, or loss, in our example).

Housekeeping

There is one final housekeeping step, normalizing the ending principal account. Our transactions hit two different inventory accounts, BUP (for Buys) and SEP (for Sells). Given our posting model, we will have balance records for both accounts. What we want at end of day is only one account, depending on the position (we have only one quantity account, the TE-Q, so no normalization is required there).

The following tables give our trial balance at three stages in our processing.

After Trading

Account				Debit		Credit
G		BUP		212
G		SEP				54
G		Cust Rec				158

After Realized P&L

Account				Debit		Credit
G		BUP		213
G		SEP				54
G		Cust Rec				158
G		PLR				1

After Unrealized P&L

Account				Debit		Credit
G		BUP		210
G		SEP				54
G		Cust Rec				158
G		PLR				1
G		PLU		3

While not technically required, it makes things simpler to have the inventory balance in one account. We make the following housekeeping entry:

SEP	54
BUP	54

This results in the final trial balance. As we mentioned, inventory (BUP) is carried at fair value.

Final

Account				Debit		Credit
G		BUP		156
G		Cust Rec				158
G		PLR				1
G		PLU		3

Final Data Structures

In this section we consolidate and review the concrete implementation as reflected within the Data Structures. We choose 6/03 as our trade date, with settlement date of 6/06. All trades are with a single counterparty (7334), but this is just to reduce extraneous rows in the positions and balances entity.

Register Entries

This table reinforces the fact that all updates to the positions and balances are through transactions. This greatly increases the transparency and verifiability of the system, as well as making it considerably easier to implement.

As there are no corrections or settlement on the trade date in this example, there are no Association entries.

Key			Type		Security		Qty		Q Distribution							Money		M Distribution						Prc		Comment
2217	1		BUY		XYZ		100		T	9012		C	7334			100.00		G	BUP		C	7334		1.00		First buy
2222	1		SELL		XYZ		50		C	7334		T	9012			54.00		C	7334		G	SEP		1.08		Sell
2224	1		BUY		XYZ		100		T	9012		C	7334			112.00		G	BUP		C	7334		1.12		Second buy
2247	1		ACCR-PLRP		XYZ											1.00		G	BUP		G	PLR				Realized profit
2253	1		ACCR-PLUL		XYZ											3.00		G	PLU		G	BUP				Unrealized loss
2264	1		ACCR-NPRN		XYZ											54.00		G	SEP		G	BUP				Normalize principal

The first three rows are the trading activity. The last three are generated during end-of-day processing (the last one is the housekeeping entry).

Positions and Balances

As always, the P&B values are simply the summation of the register entries. At this point, the settlement date figures are the same as the trade date figures, just offset three days.

This structure is described in detail in Positions and Balances, with a more extensive example presented in Data Structures. We present a brief summary here.

Each row represents a time series for a single type of data, e.g., trade date inventory. This contrasts with approaches where a given row represents a variety of data for a single position, e.g., quantity, inventory at cost, mark to market, realized P&L, etc.

The first row in the table is the trade date (TE) position (Q, for quantity) for trading account (T) 9012 in security XYZ. The next field (0) is the balance as of 5/31. Following are zeroes for 6/01 and 6/02, followed by 150 as the balance end-of-day for 6/03, and so on. (The "PRIM" indicates books and records data, rather than a memo or forecast amount.)

The third row is the money value for G/L account BUP (long principal) for security XYZ, trading account 9012. Further down are the settlement date (SE) rows.

Positions (Q) and Balances (M) — as of 6/03
											6/03	6/04	6/05	6/06	6/07	...	6/10	...
TE	Q	PRIM	T	9012	XYZ			0	0	0	150	150	150	150	150	...	150	...
TE	Q	PRIM	C	7334	XYZ			0	0	0	-150	-150	-150	-150	-150	...	-150	...
TE	M	PRIM	G	BUP	XYZ	9012		0	0	0	156	156	156	156	156	...	156	...
TE	M	PRIM	G	PLR	XYZ	9012		0	0	0	-1	-1	-1	-1	-1	...	-1	...
TE	M	PRIM	G	PLU	XYZ	9012		0	0	0	3	3	3	3	3	...	3	...
TE	M	PRIM	C	7334	XYZ			0	0	0	-158	-158	-158	-158	-158	...	-158	...
SE	Q	PRIM	T	9012	XYZ			0	0	0	0	0	0	150	150	...	150	...
SE	Q	PRIM	C	7334	XYZ			0	0	0	0	0	0	-150	-150	...	-150	...
SE	M	PRIM	G	BUP	XYZ	9012		0	0	0	0	0	0	156	156	...	156	...
SE	M	PRIM	G	PLR	XYZ	9012		0	0	0	0	0	0	-1	-1	...	-1	...
SE	M	PRIM	G	PLU	XYZ	9012		0	0	0	0	0	0	3	3	...	3	...
SE	M	PRIM	C	7334	XYZ			0	0	0	0	0	0	-158	-158	...	-158	...

Extended Example

In this section we present a sequence of days with a variety of types of activity. Day 1 is the example we've been discussing. Day 2 starts with the ending balances from Day 1 and adds its activity, and so on.

• On the left is the activity against Inventory, the Buys and then the Sells. These are in their natural signs, which means the Sells show up as positive, though they are actually credits.
• To the right, starting with the column "End Pos", are the end-of-day steps we go through to get to inventory at cost, followed by inventory at market.
• The figures on the right are in trial balance format.
• The column "AdjR" is the adjustment needed to get inventory to cost. Reversing the sign gives Realized P&L. On the first day, for instance, this figure is $1, which means their would be a credit (profit) to Realized P&L.
• The column "AdjU" is the adjustment needed to get inventory from cost to market. Reversing the sign gives Unrealized P&L. On the first day, for instance, this figure is -$3, which means their would be a debit (loss) to Unrealized P&L.
• Every day has a summary row, "EOD". Because we start by backing out the Unrealized P&L, that is shown on the row just above it in the "AdjU" column. The Buy and Sell figures are the inventory available: the beginning balance plus the day's activity.
• The TOTALS row at the end shows the sum of the activity for the Buys, Sells, and two adjustment columns.

			Buys				Sells
Day	Activity		Quant	Prc	Money		Quant	Prc	Money		End Pos	End Inv	Avg Cost	Inv @ Cost	AdjR	Mkt Prc	Inv @ Mkt	AdjU
1	Buy		100	1.00	100.00
	Sell						50	1.08	54.00
	Buy		100	1.12	112.00
	EOD		200	1.06	212.00		50	1.08	54.00		150	158.00	1.06	159.00	1.00	1.04	156.00	-3.00
2	Buy		100	1.08	108.00
	Buy - Rev		-100	1.00	-100.00
	Buy - New		100	1.02	102.00
	Sell						100	1.01	101.00
																		3.00
	EOD		250	1.08	269.00		100	1.01	101.00		150	168.00	1.08	161.40	-6.60	1.02	153.00	-8.40
3	Buy - Cxl		-100	1.12	-112.00
																		8.40
	EOD		50	0.99	49.40		0	0.00	0.00		50	49.40	0.99	49.40	0.00	1.02	51.00	1.60
4	Sell - Cxl						-50	1.08	-54.00
																		-1.60
	EOD		50	0.99	49.40		-50	1.08	-54.00		100	103.40	0.99	98.80	-4.60	1.02	102.00	3.20
5	Sell						50	1.08	54.00
	Buy		50	1.06	53.00
	Sell						150	1.07	160.50
																		-3.20
	EOD		150	1.01	151.80		200	1.07	214.50		-50	-62.70	1.07	-53.63	9.07	1.06	-53.00	0.63
6	Buy		50	1.05	52.50
																		-0.63
	EOD		50	1.05	52.50		50	1.07	53.63		0	-1.13	1.07	0.00	1.13	1.06	0.00	0.00
7	Sell - cxl						-50	1.08	-54.00
	Buy - cxl		-50	1.04	-52.00
																		0.00
	EOD		-50	1.04	-52.00		-50	1.08	-54.00		0	2.00	1.08	0.00	-2.00	1.06	0.00	0.00
8	Sell						150	1.08	162.00
	Buy		100	1.06	106.00
	Buy		100	1.04	104.00
	Sell						50	1.05	52.50
																		0.00
	EOD		200	1.05	210.00		200	1.07	214.50		0	-4.50	1.07	0.00	4.50	1.06	0.00	0.00
	TOTALS		450		473.50		450		476.00						2.50			0.00

This is what is happening on a day-by-day basis:

Day	Description
1	Our earlier example: 2 Buys and a Sell.
2	More activity: a Buy, a correction of the price on the first Buy on Day 1, and a Sell.
3	Cancellation of a Buy is the only activity.
4	Cancellation of a Sell is the only activity.
5	Going from a long starting position to a short ending position.
6	Going flat.
7	Cancelling two trades, offsetting.
8	Day trading.

We will discuss the important points from this example in Drawing Inferences.

Revised Equations

The equations we gave earlier were for a traditional inventory accounting system. While useful in understanding the broad concepts, they aren't directly applicable to securities accounting because they embody the assumption that inventory can only be long.

To restate the equations we need terms to replace some of those used earlier. We introduce these terms:

Term	Description
Rem	The side (i.e., long/BUP or short/SEP) where there is a remaining position at the end of the day.
Exch	The side that has no ending position, that is, the side that was completely exchanged.

If Rem is the long side, then Exch will be the short, and vice versa. If you are flat, it makes no difference how they are assigned.

We also replace the terms "Purchases" and "Sales" by "Activity", which we'll prefix with Rem or Exch.

It may be helpful to think of Beginning Balance (at cost) + Activity as the amount available, whether Rem or Exch.

The reformulated equations follow. Remember that the first six don't depend on the inventory cost method, while the remainder apply only to average cost. The typography conventions are the same as earlier.

1'.	Beginning Rem Balance (at cost) + Rem Activity - (Beginning Exch Balance (at cost) + Exch Activity) = Ending Rem Balance (not at cost)
2'.	Beginning Rem Balance (at cost) + Rem Activity - Cost of Goods Exchanged = Ending Rem Balance (at cost)
3'.	Realized P&L = (Beginning Exch Balance (at cost) + Exch Activity) - Cost of Goods Exchanged
4'.	Ending Rem Balance (at cost) = Ending Rem Balance (not at cost) + Realized P&L
5'.	Ending Rem Balance (at fair value) = Ending Rem Quantity * Fair Value Price
6'.	Ending Rem Balance (at fair value) = Ending Rem Balance (at cost) + Unrealized P&L
7'.	Average cost = (Beginning Rem Balance (at cost) + Rem Activity) / (Beginning Rem Quantity + Rem Quantity Activity)
8'.	Ending Rem Balance (at cost) = Ending Rem Quantity * Average Cost
9'.	Cost of Goods Exchanged = (Beginning Exch Quantity + Exch Quantity Activity) * Average Cost

Accounting Topics

There are a number of more general accounting topics which relate to our inventory accounting and trading profit & loss discussion.

Realization and Recognition

It's useful to consider the trading P&L in the broader accounting context.

It starts with recognition, i.e., whether a transaction is reflected on the firm's financial statements. For instance, orders generally aren't recognized, while trades (purchases and sales) are.

Recognition of a revenue or expense (and of a gain or loss) is based first on whether the amounts are earned. This is one reason why orders aren't recognized; the amounts haven't yet been earned by the firm. Similarly, in paying for insurance on an annual basis the full amount is not recognized as an expense when the invoice is paid up front. Instead it is booked as an asset, with the expense recognized on a month-by-month basis (this is a a deferral).

The second consideration for recognition is whether the amount is realized or realizable. Realized has to do with conversion to cash or a claim of cash (e.g., the counterparty receivable on a Buy). Realizable replaces "conversion" with "readily convertible". The purpose of the standards on fair value that we saw earlier is to insure that the amount is readily convertible. It's all very well to think that your penny stock is really worth $100/share, but that is not enough for you to include the profit on your books.

Our Realized P&L is realized because of the matching of Buys and Sells reflected in equation 3'. Our Unrealized P&L is the realizable component.

All P&L is obviously realized or realizable; otherwise we couldn't recognize it. Receiving coupons payments or dividends are also realized, for instance. In the securities industry, however, realized P&L and unrealized P&L are used to refer specifically to proprietary trading activity.

For more information see ¶'s 6, 83, and 84 of [FASBCon5] and ¶ 143 of [FASBCon6]. See also the terms cost (a series of terms), holding gain or loss, inventory equation, inventory profit, realizable value, realization convention, realized, realized gain (or loss) on marketable equity securities, realized holding gain, and recognize in [AcctLangBus05].

Periodic and Perpetual Inventory

In our discussions we have adjusted inventory and recognized P&L at the end of the day. This is an example of periodic inventory accounting, with the period being one day. It is customary in the industry to proceed this way as part of the back office end-of-day books and records processing.

The other approach is to update the books with every Buy or Sell. This is sometimes done in front-office trading systems so that the traders can see their positions and performance (realized and unrealized P&L) on an up-to-date basis. This is using the perpetual accounting basis.

The problem is that at the end of the day the cost of inventory (and thus realized P&L) for the two approaches generally won't match. In our original example, the perpetual inventory approach results in the figures on the FIFO line of the cost table. Realized P&L differs by $3, unrealized by -$3, and Ending Inventory (at cost) by $3. The question is whether the benefits outweigh the cost of the effort to reconcile to the books and records. Total Economic P&L is the same, of course.

See these terms in [AcctLangBus05].

Total Economic P&L

The sum of realized and unrealized P&L is sometimes called total economic P&L. Combining equations 4' and 6' we have:

TE'.	Ending Rem balance (at fair value) - Ending Rem balance (not at cost) = + Realized P&L + Unrealized P&L

The right hand side is total economic P&L. For a given trading situation, if we change the cost method, we will (probably) change Realized P&L. But because the left hand side is fixed, this means there will be an offsetting change in Unrealized P&L to keep total economic P&L unchanged. All the cost method does is affect the split between realized and unrealized.

This applies to all situations where fair value is something other than cost (this is another way of stating equation 6').

Alternative Approaches

We've mentioned a number of different ways that the subject can be presented and implemented. In this section we address some of the alternative approaches that can have the greatest impact on the implementation.

One vs. Two Inventory Accounts

The Framework for our discussions has been based on the use of two accounts for inventory principal, one associated with Buys (BUP) and the other with Sells (SEP). The alternative is to have a single inventory principal account, against which all inventory postings are made.

The primary reason for having the two accounts is to support the realized P&L algorithm. Simply knowing whether a posting is a debit or a credit is not enough. A cancel of a Buy will be a credit, but it is very different from the inventory credit associated with a Sell. We saw this in the Day 3 realized P&L. If you use a single inventory principal account you are forced to use an attribute-based approach (see Distribution vs. Attributes).

Occasionally a user (usually in accounting) will inquire about having "negative debits" or "positive credits". In most cases they are looking for a way to distinguish reversals (e.g., for a Buy) from direct entries (e.g., a Sell). The effect on the balances is the same, but using two accounts makes many things much simpler.

The one drawback to using two accounts is the step of tidying up the balances (see Housekeeping).

Distribution vs. Attributes

We gave the algorithm for realized P&L in two forms: English and Framework. The English version is the more readily understandable to the users, of course, and this is its great benefit.

Unfortunately, this is not a particularly useful guide to developing a system to satisfy the business requirements, though you encounter it frequently in the industry. Such implementations typically rely on a variety of fields to determine how P&L / inventory are going to be affected. Examples are:

• The transaction type, e.g., whether it's a Buy or a Sell.
• A cancellation or a correction or correction flag.
• Journal code, to determine how bookkeeping entries are handled.

There are a number of major limitations to such an approach, including:

• This duplicates logic required for updates to the positions and balances.
• Any new transaction type will require changes to the program code.
• Handling of special cases is often troublesome, e.g., a day where the only short activity is a cancellation.
• The programming in general is quite complex.
• Transparency is limited. All the logic is interpreted at run-time, and the only persistent outcome is the values for inventory and P&L.
• It is not easily extensible to other types of instruments, where the transactions are represented differently.

The alternative approach is to build the accounting effects into the system architecture, as is done with the distribution component of the Framework. As we've seen in the discussions above, this reduces the algorithm to one of selecting Register entries that affect one or two of the inventory principal accounts. The drawback, of course, is that it is more abstract, which may be a drawback for the users or the IT staff.

The benefits, however, are major and real.

• There is no consideration of anything other than the long and short inventory accounts. The only dependence is on the values that directly determine the necessary postings, so the development focus stays on the most important factors.
• There is no new programming required for new transaction types or other system changes.
• There is no programming required for other instruments. As finally presented, there was nothing specific to equities. The Framework version of the algorithm applies to any instrument where the firm has proprietary inventory. It applies exactly to fixed income (bills, bonds, and notes; Treasuries and corporates), options, futures, and anything else with inventory.
• The logic is based directly on the fields (i.e., distribution) that are used for updating positions and balances.
• There is a high degree of transparency. It is simple to print out all transaction which book to inventory, and what their affects are (long vs. short, debit vs. credit).
• The programming is generally straightforward.

It is not a coincidence that the accounting-based approach works, and that it works so well. The accounting for securities transactions has been developed over decades specifically to support the functions we've been considering. The standards that guide the requirements are written in those terms. In fact, if you're using an attribute-based approach your logic is doing nothing more than backing into the inventory principal effects of each transaction.

Inventory vs. Cost of Goods

In Cost we saw that fixing any one of the three unknown amounts determines the other two. Our approach focuses on determining Ending Balance (at cost).

The other (and probably more common) approach is to determine Cost of Goods (determining Realized P&L directly requires performing one of the the other calculations as part of the procedure). The inventory equation (equation 2) encapsulates both approaches.

In Accounting for Cost we saw that (in other industries) Cost of Goods is an account in the chart of accounts, requiring an explicit posting. In terms of the Revised Equations, you set Cost of Goods Exchanged = Exch quantity available * (Rem balance available / Rem quantity available). It is often referred to as a process of matching Buys and Sells.

Is there a reason to prefer one approach over the other? We prefer the Inventory approach for a number of reasons:

• Cost of Goods is not an account in a securities industry chart of accounts. We have no postings to make to it. This is not to say that it doesn't have use as a report-time (and thus derived) value.
• The corollary of this is that we do have the account Realized P&L, and do have to post to it.
• The Inventory approach is simpler (there is no need to consider the Exchange side data at all), so we avoid needless programming complexity.
• Any algorithm can generate rounding differences. When you go flat, the Inventory approach always takes the inventory balance to zero. The Cost of Goods approach can accumulate differences over the life of the position, so that you end up with no quantity but with money in the principal balance account. This normally leads to special journal entries to clear it out, which is another unnecessary, time-consuming process.
• The Inventory approach leads to insights you don't get with the Cost of Goods approach.

The point about going flat is an instance of a related, but slightly different issue. The Cost of Goods approach focuses on activity rather than balances. The Inventory approach focuses on the balance in principal. It is almost always easier to reconcile to a balance than to an activity, because the balances (e.g., cash balance, amount of inventory) is often independently verifiable. Incremental approaches (such as Cost of Goods) are prone to drift, with errors accumulating over time.

Drawing Inferences

We now take a step back and take a look at some of the things we can learn from this discussion, beyond the mere mechanics. A number of the points relate to days of the Extended Example.

Review Questions

A great amount of information has been presented on this page (and the others on this site), of both a conceptual and detailed nature. It is one thing to read passively and another to internalize and apply it. In this section we present two questions to consider, one on the business concepts and one on the technical approach. Both questions arose in production environments and represent real-life issues.

We encourage you to consider either or both of these questions. If you would like to discuss them, please feel free to e-mail us at RQ-PnL@eclipsesoftware.biz.

P&L Reconciliation

It is usual to have trading P&L calculated in (at least) two systems, both utilizing a weighted average P&L approach:

• The front-office trading system. This is used by traders to monitor their performance.
• The back-office books and records system. This is the official P&L for the firm.

This situation naturally gives rise to a reconciliation process between the two systems. As the users and IT staff look at the results from day to day, a number of questions arise:

• What can be the causes of the differences?
  • For realized P&L.
  • For unrealized P&L.
• What is the effect of pricing differences?
• What is the effect of trades being handled in one system later than the other?
• What is the effect of cancellations being handled in one system later than in the other?
• What is the effect of corrections being handled in one system later than in the other?
• What is the behavior of the errors over time?
  • Can the errors accumulate over time, growing ever larger?
  • Will they go to a certain level and tend to settle there?
  • Will they tend towards zero long term?
  • Is there any general behavior that can be identified at all?

The question for you is to answer these questions. If you've internalized the material on this page, the answers should be almost immediate, requiring little analytical reasoning.

Handling Re-runs

We mentioned that our intent was to provide a complete algorithm, one that can handle all relevant occurrences (e.g, calls and conversions, cancellations, corrections, assignments and expirations), not just trades. We believe we have presented a complete framework, though we have not detailed how every occurrence mentioned above would be implemented in the Knowledge Base. While it would be useful for you to consider that effort (it's fairly straightforward), we have a different sort of question in mind.

Consider the situation where end-of-day has been done and P&L calculated. It is then found that certain trading activity for the day has not been entered into the system and management wants it input and the P&L re-run. They do not want to do it on an as-of basis.

The problem is what to do about the entries generated by the earlier run. The entries are PLR vs. BUP or SEP, and PLU vs. BUP or SEP. According to steps B and C of The Algorithm within the Framework, these entries will be picked up and result in incorrect calculations.

The questions are:

• Why will these entries cause errors?
• What kind of errors will be created?
• How do you insure that re-runs avoid errors and generate the correct P&L?

The last is really a question about the Architecture more than P&L calculation. There are many way that it can be addressed, but really only one that maintains simplicity, cohesion, and conceptual integrity.

Copyright 2005-2021, Eclipse Software, Inc (ESI).  E-mail: WebSite@eclipsesoftware.biz.