I find that often the "marketing" entities don't correspond exactly with internal entities. In such cases, it makes more sense to introduce an entity at a different level of abstraction, which makes the terminology differences a moot point.
For example, we have a model that represents a hierarchy. Each level in the hierarchy has a term associated with it based on how the hierarchy is used to model real-world relationships, but internally there isn't a difference in behavior from one level of the hierarchy to the next. The terminology is essentially just a name for that level in the hierarchy, so for a particular node in the tree the name simply describes what the node is; it doesn't prescribe any particular behavior.
Also, the tree is multi-rooted, so there are several nodes without a parent. Even though conceptually a root exists (it would essentially represent the universe), and including it in the model would many operations much simpler, there is no "marketing term" for it.
Of course, different components in our system use different terminology. They were developed at different times by different teams, and we don't have control over all of them. Actually, at some point, someone added or removed a level in one component, and so the other levels are shifted relative to each other. The same three levels are represented by A, B, and C in one component, but as B, C, and D in another.
Taking a step up in abstraction and simply modelling everything as a "node" or something equally generic makes these kinds of models a lot easier to reason with. Each node knows what its "marketing term" is, and the type that represents a particular marketing term can know what that term means in each context.