Why CFOS Cannot "Interpret the Value" in a cell

These messages can take several different forms:

• Unable to interpret the value in the {Income Statement | Balance Sheet} Row: {row_num} Column: {column_num}. We were expecting a number but found letters or other special characters
• Unable to interpret the value in the {Income Statement | Balance Sheet} Row: {row_num} Column: {column_num}. The type of cell is not supported. It must be blank, numeric, string, boolean, formula, or error.
• The cell of type {cell_type} is not supported in the {Income | Balance Sheet} statement; Row: {row_num}, Column: {column_num}.
• The cell of type {cell_type} is not supported in the {Income | Balance Sheet} statement header; Row: {row_num}, Column: {column_num}.
• Unable to interpret the value in the {Income Statement | Balance Sheet} Row: {row_num} Column: {column_num}. We were expecting a string or a blank cell.

Basically these all boil down to one key idea: CFOS expected a certain cell to contain a certain kind of value, and instead it found something else.Usually this is one of just a few things:

1. The numeric accounting figures contain some non-number content. For instance sometimes client spreadsheets will contain literal hyphens (-) or parentheses, which will visually blend in with the way Excel visually displays accounting figures. Sometimes cells will contain nothing but a period or a comma, or some other punctuation. To get rid of these you can select all numeric accounting cells and use Excel's Data Validation tool to highlight any non-decimal values. That usually takes care of it.
2. Occasionally some character will make it into the account name columns that shouldn't be there. This is rare and would need to be something very exotic such as uncommon diacritic marks, foreign currency symbols, or special symbols like wingdings or dingbats (yes, those are actual things). These can be harder to find however the Data Validation tool can be useful in some circumstances. Typically your eyes will do a better job with these.
3. Very rarely, an otherwise-good row of date headers will contain a mistake which disrupts the whole flow of the pattern. For instance, clients that prepare their statements with manual effort might have something like Febuary at the top of one of their columns. This won't get recognized as a date, because it isn't a word! So look for any inconsistencies in the pattern of date headers.
4. This error can sometimes refer to just a general failure of the layout of the document, meaning the client located the right information in the wrong place. Review our general requirements again if you're unsure about this.