Hi Antonio,
your example with the secretaries is an example of procedural programming. It's very directive: "you, do this, you do that". In Axon, things are turned around. Things become reactive. It's more like you shout through the hallway: "HEY! We're starting a new audit for xyz". As a result, your secretaries will know that they need to bring you information. When you have all the information, you shout, ehm... whatever you need to shout.
Typically, you should prevent the need for aggregates to fetch information from another component. That's not always possible or feasible, though. Sometimes, aggregates need access to domain services (as defined in DDD by Evans) to help them make sense of information.
Regarding your last email, with the code examples, I noticed a few things. First, you use a GetProcessCommand to retrieve information. Since the whole thing is not about changing any state in the application, it a query, not a command. Queries can be implemented using a command-like structure, but generally, they're just repositories.
EventHandlers inside aggregates only fire for events that are generated by that same aggregate. That's because aggregates don't (and shouldn't) listen to the event bus. Since Axon 2.2, it is recommended to use the @EventSourcingHandler on methods, to make that difference clear. Events generated by aggregates are sent to the Event Bus by the repository when the Unit of Work that loaded the aggregate commits. Normally, this is done by the Command Bus.
Unlike you, I am not an auditing expert with 6 secretaries at my service (*sigh*), so I don't really know what should be happening. I can imagine that you need to go through each file and make sure that the entries in one file match the entries in another. Perhaps the aggregate can be seen as a stream processor. Just feed each entry as a command, and the aggregate will start shouting down the hallway (Event bus) when something interesting happens. Alternatively, you could pass a "token" with which the aggregate can stream information from some sort of repository itself. The latter is less efficient, as aggregates tend to work best when they execute short actions.
That brings me to a last remark: not all processes are suitable to model using aggregates and entities. Sometimes, something is just a batch process. The batch process can still be triggered using a command, and spit out events. So you can still use the Command Bus and Event Bus, but leave the Aggregates for what they are....