Event sourcing vs CQRS: when do you actually need both?

We're building a financial ledger system at work, and event sourcing feels like a natural fit for auditability and reconstruction of state. Every state change is an event, which is appended to an immutable log. The question then becomes, do we also need CQRS (Command Query Responsibility Segregation), or is that overkill? Event sourcing gives us the source of truth, but querying it directly for complex views can be cumbersome and slow. This is where CQRS comes in, creating separate read models optimized for specific queries. For a financial system, having a read model for 'account balance at time T' is appealing. However, it also adds significant complexity: maintaining eventual consistency between the event store and the read models, handling schema evolution for events, and managing multiple data stores. In practice, when do you find both event sourcing and CQRS are truly necessary, and when does CQRS add too much overhead for the benefits it provides? How do you manage the schema evolution challenges for events that inevitably arise?