Database design of Ledger Account and Balance sheet generation

I really have to encourage you to look at the way DB schemas are handled by existing CRM systems and consider whether (1) you wouldn't be further off customizing one of these systems and (2) you're not biting off more than you can chew.

Most CRM systems I've seen have extensive customization capabilities built into them. Typically, this includes the ability to extend and/or modify the definitions of the built-in entities and the ability to add new entity types and relationships. Many of these CRM systems also have the ability to set up some pretty funky security setups, and some might be able to do something similar to what you're suggesting.

I'd also encourage you to try to pry a business scenario out of this client, as well. What's got him convinced that sales reps are going to share information? If they're working together on a team, then existing CRM systems have this covered already. If not, then I'd be a little suspicious about the premise of information sharing. Understand that sales reps are going to follow the money with respect to their behavior. If they're paid to share information, then it'll happen; otherwise, you're going to have to beat them with a stick to share anything.

A rule of thumb I use, is that it's bad database design to have to alter a table to accomodate a code change or a new feature if it can be planned for in the future.

That said, I would use a variant of Option 1

Approvals
    Id PK
    ApprovalTypeID FK
    Status


ApprovalComments
    ID PK
    ApprovalId FK
    Comment

ApprovalTypes
    ID PK
    Name

Now when adding new types of objects that need approval, you only need to insert a row into ApprovalTypes instead of altering a table to add a column.