Version control of financial models is essential. Many times we have seen the wrong version go to the wrong counterparty and this should be easily avoidable.
If you have a file based system, then we recommend that each discrete model have its own folder and that you use a consistent naming convention as follows:
- Prefix: Each model should begin with the same name (e.g. “XYZ financial model”)
- Separator: We then recommend segmenting the name with an underscore to separate the model name from the versioning nomenclature.
- Version Number: Many model we see includes dates for versioning. There are so many obvious reasons why this is a bad idea for sequentially changed models. What if there are two (or many more changes) on the same date? Do you then use a lower case letter or something else? (Which is only obvious when looking at the prior version.) A much better approach is to just use sequential numbering with several leading zeroes (generall we use five). Now, if a model is deleted, then we know exactly where the gap is. You do not have to train people to use yyyymmdd format for ordering, which most people will not abide by. Let’s just say there is a reason databases use sequent number ordering when creating primary keys in databases, not the current date followed by some additional unique identifier. While seeming ovsious, this has been a source of many needlessly frustrating conversations.
- User: The next set of characters are the initials of the user. Depending on the uniqueness and overlap, you may want to adjust this, but two or three character initials gernally work well for identifying the last saver.
- Purpose: We might then append the purpose or use of the model followed by an additional underscore. For example, “_sent of Jan 1”. Sometimes date meta data is useful, just not for versioning.
- Avoid: One character to avoid in naming models is the “.” or dot. When working on your files programatically, it is best to leave the dot as the character before the file type extension (e.g. “.xlsx”). It makes for easier parsing and also cleaner looking file names.
So here is a full example: “My Financial Model_v00001_ABC_sent Jan 1.xlsx”
Yes, this is a bit opinionated, but that is necessary to have consistency in your files in an organization large or small.
A clearly better alternative is to store your models in a system like Structrz, which will take care of version control for you and will label files in a consistent manner when exporting to Excel. Structrz can also retain all the meta data so you do not need to worry about clogging up the file name. But if you are not using Structrz, please create a policy document to get alignment on file names internally, but don’t be surprised when it is difficult to enforce.