Monthly. Is there much more to say? The size of spreadsheets and the speed of computers had made it much easier to have a longer periodicity for analysis. But Excel spreadsheets are still resource constrined, for some non-obvious reason. And it is still worth considering some of the trade-offs, especially with monthly versus quarterly models.
Monthly/Quarterly: Pros and Cons
| Monthly Pros / Quarterly Cons | Quarterly Pros / Monthly Cons |
| – Monthly tends to be the smallest period where financial data is determined. Revenues and expenses are usually down to the month. When items use partial months, moving to days would increase datasets too much and it is usually easy enough to pro-rate. – Certain items like construction schedules will always need to be monthly and models that start monthly and then go to quarterly are very unwieldy. As soon as you need an extra month, the model needs a lot of work. – Monthly IRRs will generally be the most reliable. Daily IRRs should not be too different, but quarterly IRRs can be off my a meaningful number of data points. – Auditing a model will likely be easier if it is monthly. Timing can be lined up more easily with contracts and comparing two monthly models will almost certainly be easier than comparing two quarterly models that will likely use different pro-rating approaches. | – file size is still a consideration and this is probably the biggest issue wtih monthly models. – Calculation time is slower. There are a lot more dependency trees to create and this will always come at a cost. – Model navigation will be faster with quarterly models. We see some amount of freezing when monthly data is used. – When there are a large number of projects in a portfolio model, monthly models can get bogged down. |
Of course, if you are using a system like Structrz, then the number of periods is less of an issue because (a) we can use virtually unlimited compute to calculate models in parallel when there are no dependencies, (b) we can render just the part of the spreadsheet when needed, again on fast servers that are not constrained like Excel, and (c) We can isolate lots of parts (like inputs) of the spreadsheets so the entire file is loaded for every manipulation. If we wanted to, we could also set up Structrz calcuations to be quarterly or annual, if we think the trade-off is worthwhile. We would get calculation speed improvements. It would also be possible to convert between monthly and quarterly using the same inputs, though it would take some effor to build this in and it is not clear there is demand.
We have not mentioned annual calculations. There are certain accounting items (like capital accounts that need to be calculated annually. In general, we opt for just using the last month of each year for these calcs so that the cells can be used if there are dependent monthly calcs. For depreciation, we create an annual table, but it is fairly isolated and it would be very to follow the calcus if they were monhtly, but we may add such a schedule in time.
There are certain other cases where annual calcs are warranted, especially in quick and dirty spreadsheets that are not trying to approximate reality. The IRRs do deviate more the less granular the data. In time, we are likely to build into Structrz the ability to have quarterly and annual calcs for certain cases, but we still think monthy is the best place to start, since you can alway aggregate to quarterly and monthly, but it is much harder to go in the reverse direction.