So just to clarify. if i have a clustered index on say contactid and invoiceid however none of the updates are on those columns then there wouldn't be a need to reorder on update correct? is there any overhead related to the clustered index if updates are applied to columns that arent part of the clustered index?
If those are the key columns in the Clustered Index and they never get updated, only inserted, AND they are inserted in an "ever-increasing" order, then there won't be any extra overhead there because they won't be causing any page splits.
If contactid and invoiceid are the keys to the clustered index, and you change either, especially the one that is the first column of the clustered index, then that WILL lead to some pretty massive fragmentation due to page splits because the rows will actually have to move to another page in most cases for the lead column and in some cases for the second column. If either are NULL and you update them to something else, that almost guarantees rows being moved from one page to another and that will almost guarantee a page split. It'll also guarantee some partially full pages so you could end up with some pretty low page densities where rows used to be NULL but were updated to something else.
If contactid and invoiceid are of a numeric datatype and you don't have row or page compression happening and they aren't part of the clustered index keys, then they won't cause row movement and they won't constitute an "ExpAnsive" update and that won't cause any fragmentation.
All that's fun until someone starts throwing updates on other columns...
Read the second paragraph in Scott's post above (and to emphasize what he has correctly stated)... It doesn't matter if columns are part of the Clustered Index keys or not. If ANY column is variable width and it's updated from NULL or something small to something bigger (maybe even only by 1 byte), it might only take ONE of those to cause a page split and the resulting 2 types (logical and page density) of fragmentation. That also includes many normally fixed length columns if you have either row or page compression going on the table.
And, lowering the FILL FACTOR WILL NOT HELP IF you do INSERTs on an ever increasing Clustered Index and then turn right around an do such an "ExpAnsive" update before the next rebuild because all such INSERTs will be going in at the "hot spot" at the end index and they will fill those pages as close to 100% as possible.