I don't know. Obviously I'm still missing something trying to help you. I've seen duplicates in the sense of repeated names. The city of Columbus exists in Ohio and Georgia and probably others. But they are different cities sharing the same name. In this case, it's the same accounts appearing in two different levels of the same hierarchy.
Not really the same thing. What do you do if you have a single record in your fact table like "Date 2008, City Columbus, Value 10"? How do you link this single value to each Columbus city, each with its own unique key? That would be an one-to-many relationship, but I imagine that if you have 3 distinct cities you'd have 3 distinct records in the fact table, because each city in itself is unique and that makes sense. Here the account is one and the same, with only one value, the user just wants it adding in one group and substracting in another one.
What's not working that you need? I've also used these before, but again, not with the same account at different levels.
Read here for many-to-many and unary operator issues. The exact same thing happens here. The proposed workaround is the one already discussed here, duplicate the recods in the fact table, which is not really a solution, as we have already discussed. The last comment in that blog wonders about the same unwanted duplication. If you google "many to many unary operator" it seems it's a well known problem with no solution.