Cash: 0:36-2:30

Accounts Receivable- 2:31-7:18

Inventory: 7:19- 12:22

Fixed Assets: 12:23- 16:16

Custom Assets: 16:17- 17:43

Understanding how any asset on the balance sheet impacts cash:

By default, an increase to an asset on the assets page (as in accounting) represents a decrease to cash. For example, if you buy a building that building will then be listed as an asset with a value on the balance sheet. Well, you had to use cash to buy that building so the value of the building will be shown as let's say $100,000 but if you spent $100,000 in cash to buy the building then we need $100,000 to come out of cash. Since you received something worth $100,000 in exchange for our $100,000 in cash then our total assets in our possession haven't changed but it's still important to show the changes in how our assets are now distributed because we have $100,000 less in usable funds since we can't pay bills with our building- we need cash for that.

By default the cash balance in a given month always assumes that revenue we show on the revenue streams tab was received in the cash balance. This means that when we use accounts receivables the change in cash isn't a true "cash event" that costs us money- instead the cash balance fluctuates to counteract the revenue that is already being added to the cash balance by default.

"Starting Value"- If an object already existed on the balance sheet before the model start date then the fluctuations to cash for this object have already been factored into our current cash balance. This means we need to tell the model how much of this asset's current value from the balance sheet to ignore so that it doesn't fluctuate cash and show us "paying for something" we've already paid for.


You should always have a cash object in your scenario for your model. If you don't have a cash object added you'll notice that your financial statements do not keep an accurate account for cash. If it's not added into your model- add it using the "Add Asset" button.

How to add starting cash balance:

1) Open Starting Cash Object by clicking the 3 dot menu next to the "cash" object on the page.

2) Then click "edit" next to starting cash and insert the value of your current cash balance into the "Initial Value" field.

Accounts Receivable (abbreviated as A/R)

This represents a delay in when revenue is physically received vs. when it is recognized as having been generated. For example, you make a sale in February but the party paying you is not expected to pay (and create usable funds for you) for 60 days. The length of time the party has to actually send you the funds (and make them usable to you) is known as the "payment terms". This number of days is entered within the "Days on Hand" input metric's value field to make the Accounts Receivable object function.

By default the cash balance in a given month always assumes that revenue we show on the revenue streams tab was received in the cash balance. This means that when we use accounts receivables the change in cash isn't a true "cash event" that costs us money- instead the cash balance fluctuates to counteract the revenue that is already being added to the cash balance by default.

Days Receivable- If this input is "0" your A/R Object wont do anything. That's because you're effectively telling the model there are 0 days delay between a sale being made and the funds being received and in this case, you wouldn't need A/R. Change the value of "0" to the number of days you want to delay making a sale and receiving payment.

Days in Month- This value is "30" by default and should always be "30".

Receivables Turnover Ratio- This takes the days receivable number and divides it by the days in month to create a multiplier that represents "how much" of the revenue received in the month is going to be delayed. For example, if you set the Days Receivable to 30 then you're saying the funds are delayed by a full month. The receivables turnover ratio will increase the value of your A/R by the full value of revenue (for the month). Using the explanation above of how assets affect cash on the balance sheet we can see then understand that this asset value going up represents the money NOT going to cash and when the asset value falls the funds are then going to our cash balance.


Inventory is simplified greatly within our platform and only a cost accounting of inventory (what the impact of inventory is on cash on hand) is being tracked. If you're looking to track inventory behavior (specific amounts of inventory on hand, lead times between materials etc.) you'll need to use a dedicated inventory management system outside of the model. The model uses your cost of goods sold expenses to determine the cost for making products and then says you replace X amount of days of that product in a typical month to prepare for future sales. This means the higher the value of your "Days on Hand Metric" the larger impact to cash as you replace more inventory / purchase more inventory in anticipation for future sales.

It makes sense that if I say I sell 1 pair of shoes for $100 that there is some cost of materials, labor, shipping, etc. for making that pair of shoes. These are my cost of goods sold and effectively, knowing my cost of goods sold tells me what it costs me to make and deliver a pair of shoes every time there's a transaction. Knowing this amount, all the model would then need to know is the number of days worth of shoe sales I need to anticipate and replace from my cash balance to make an accurate assessment of how much its going to cost me today for my inventory that I'm relying on to make sales in the future and this is exactly the information the model uses between the "Cost of Goods Sold" metric and the "Days on Hand Metric". For example, if I only want to replace one month's worth of sales at a time then my "Days on Hand" is just 30. This will tell the model to look at my total COGS for the month and order that much in future inventory today so that my cash decreases. If anticipated storing more inventory than exactly what I need, that would raise the value of my "Days on Hand" metric.

By default, the inventory object looks at all cost of goods sold expenses to determine the cost of inventory but this can be adjusted by editing the "Cost of Goods Sold Metric" and instead altering the formula to the specific expenses that should be accounted for.

Fixed Assets

Land Purchases, Building Purchases, Intangible Assets such as IP or Patents.

Amortization vs Depreciation- Depreciation is showing the decrease in an asset's booked value as it's useful life gets shorter and shorter and this relationship applies to both tangible / physical objects like computers, equipment etc. as well as intangible items such as intellectual property, and patents filed. When something is intangible, depreciation is referred to as "amortization. Although the platform doesn't currently show the word "amortization" and instead refers to all behaviors of this type as "depreciation", the impact is still captured accurately on the statement of cash flows , balance sheet, and income statement. This meaning, depreciation isn't treated like a physical outflow of cash because, for example, if you have a car and it loses value each day you don't have to physically pay actual "cash" to anyone. It also means depreciation expenses are shown on the income statement and the "asset value" takes depreciation into account and lowers month over month on the balance sheet as more and more depreciation is accumulated.

Common Useful life values:

Patent / IP - 20 years (240 Months)

Computer Equipment / Furniture - 3 to 6 years (36 months - 72 months)

Land / Buildings - 30 years (360 months)

Custom Assets

For any objects that aren't listed in the dropdown list you'l be adding this as a "custom" asset.

A common practice is to add entire categories of assets to the model using custom assets, for example, "Total Current Assets" to capture the impact to your cash balance through changes in the asset value but without needing to transfer the entire content of your balance sheet line by line into the model. Avoiding recreating your accounting line by line can altogether make your model easier to understand, present, and maintenance.

Did this answer your question?