When you have time-dependent reports, which depend significantly on other time-dependent data like "when did which a team member belong to a team", you need to track the history of all relevant records if you want to get the reports right. And, of course, when you run the report, you have to tell the system for which date you want the report, so if you run the report on April the 10th, but want a report still for 31/03, you will get exactly that.
So in your example, you could have three tables "Person", "Team", and "Membership", where membership needs to contain date range attributes. In this approach, there is no denormalization involved. With this model, it should be straightforward how to include the given date for which the report is requested into the query.
It seems you believe this has something to do with the organizational hierarchy model - that is probably just a misconception, because that part of your model currently does not track history correctly. The same problem would appear with any other kind of data, if proper date/time stamp fields were missing.
For some kind of systems it is ok to avoid the explicit modeling of dates, because every month or quarter you make a full freeze of the data, set up a new copy of the database, and run reports against the freezed version of the db. But in general this approach is often not suitable, since you need finer granularity or do want not take the burden of dealing with these freezed database copies.
If you are in a situation where you cannot easily change the core data model (maybe your CRM is a third party product, as you mentioned), instead of freezing the db at a whole, it may be more suitable to make an automatic snapshot of all relevant data in your database to some extra tables at the end of each month and run your reports against this snapshot. These tables could be part of your "enterprise db", maybe in a separate schema "per month", or they could reside in a special, lightweight "reporting database". The controlling parameters which might be changed afterwards for "business reasons" should be made part of the snapshot, too, but you have to offer a feature to adjust them afterwards without changing the "core data".
Separating the reporting from the "standard OLTP processing" can have some additional benefits regarding performance and availability, especially if this is a "big" system.