I just launched my Financial Essentials Pack, which provides a number of key financial formulas to use in your Coda docs. The main areas covered are 1) discounted cash flow analysis (NPV, IRR, XIRR), 2) loan and annuity calculations (Payment, PresentValue, FutureValue, Rate, and Periods), 3) working with fiscal dates, and 4) some date calculations that are not directly available in Coda.
Please contact me at firstname.lastname@example.org with any questions, bugs, or feature requests.
This Pack is free for now until Coda launches its Marketplace for third-party Packs.
Dear @Todd_Olson ,
That’s awesome. I can now moving some of my financial calculation to Coda.
can you give some examples?
In excel you have many smart fin functions directly that even follow your set up, while in Coda you need to set up your tables properly before you start calculating. This makes formulas as such less flexible in my opinion for they require a certain set up (unlike Excel).
I am not yet a fan of this sort of packs, I guess that smart templates with dummy date would be a better way to proceed. Maybe I am mistaken, open for corrections!
@Christiaan_Huizer, I made a support doc entitled Financial Essentials Support for the Financial Essentials Pack that has a few simple examples using formulas in the Pack. I hope this helps give some idea of how the formulas can be used.
A big congratulations to you @Todd_Olson on launching this pack. I am looking forward to playing around with it over the coming weeks. Thank you!!!
thanks @Todd_Olson for adding this, as such the set up makes more sense to me. However we should not forget that on larger tables these formulas will slow down your work quite a bit. Anyway for starting Coda users, this might be what they need to get started.
Even on larger tables, such as for a full financial model, the financial formulas would be commonly performed only a handful of times, so I do not anticipate significant slowing. But it would be very helpful to know if you (or any users) experience such slowing.
Most of the financial calculation are done one-off. And for the performance, I think Coda still can handle it.
Of course if you are trying to calculate 10 years and above, it will take some time in Coda. In my testing, it is taking about 30 secs.
very interesting and you are right, in these kind of calculations you Coda will be fine. I had a bit more complex calculations in mind, various scenarios like I use to work on when it comes to investments.
what I see, is this how you created a Coda doc? Thus a kind of spreadsheet logic inside Coda? It looks good and I guess everybody understands it directly, no confusion.
merci for the sharing, Christiaan
Hey, @Christiaan_Huizer, take a look at my Time & Money doc for an example of a Coda doc that takes an approach to financial modeling that does not use spreadsheet logic and that tries to demonstrate numerous advantages over spreadsheet-based modeling.
thx @Todd_Olson , this one looks good due to grouping. However if you are not familiar with Coda, you might confuse this with a spreadsheet logic (which of course it is not).
Good luck with the scenarios and I am curious which users you might convince with this tool.
Off-topic: financial calculations, in particular when time is involved, can be very tricky and error prone. Regardless of the technique that is used, working with the wrong assumptions gives you wrong results.
I am not sure about the underlying formulas in this example from @Hendrik_TnB , but the total of payments is off by a good $1K, because somewhere in this spreadsheet the assumption is made that there are (exactly) 52 weeks in a year. I don’t think turning of rounding will solve this, but I can’t check because I don’t have access to this doc.
My point is that if you start using formula’s, pre-baked or written out by hand, all formula’s should give the same answer.
In this example, 30 years of biweekly payments will result in 782 payments, with a little lower biweekly payment than calculated in this example. In my way of thinking and working, there is no such thing as ‘almost good’, it is either good or it is wrong (apart from accepted rounding differences).
We tend (in particular in excel) to accept the outcome of our carefully crafted formula’s, and very often it turns out that somewhere in the underlying formulas a tiny mistake makes a big difference. By the time the results for hundreds or thousands of clients end up in a pivot- or grouped table, the differences can be very substantial and nobody might notice.