I want to call attention to one of your business rules: Representative is Customer and is Company.

This sounds like a superclass/subclass situation to me, and I think you have the EER diagram well in hand, as far as ER modeling goes.  Where things start to get interesting (and a little messy) is when you try to switch over from an ER model (which is abstract and implementation neutral) to a relational model (which is not).  

At this point, you'll have to choose between a few well known techniques that make up for the fact that the relational model doesn't incorporate inheritance.  You may wish to include this tag in your original question:  [tag:subtypes]

Here are three of the techniques in a nutshell:  single table inheritance, class table inheritance, and shared primary key.

Single table inheritance lumps all the subclasses together in one table.  Data that does not pertain to a given instance is left NULL.  

Class table inheritance has one table for the superclass and one table for each subclass.  Generalized data goes in the superclass table, and specialized data goes in the appropriate subclass table.

Shared primary key enforces the one to one nature of the relationships between each subclass and the superclass.  It also allows a foreign key elsewhere in the database to reference the superclass without knowing or caring which subclass it belongs to.  

For a good treatment of this subject, look up Martin Fowler's treatment on the web.