You wrote:
I think that a project shouldn't have a reference to the ID of the invoice aggregate root, because really the invoce it is not needed for the logic of the projects, just to know the relation between them.
That is a perfectly valid point of view which also fits to the normal life time of these objects:
First, someone defines some project containing a list of services. Those services are constituting the project, so they could be part of the projects's bounding context.
Assumed this is a paid project, the service provider will create one or more offers for those services. Depending on the size of the business, these offers may require a formal ID, or they could have just a date and description in text forms about the services offered.
Next, a customer creates some order for the offered services. That order will usually get an ID under which the account staff can store and find it. It will also have a relationship to the former offer - maybe it's ID, maybe given in text form (but if it is just in text form, someone from the service provider will have to associate the order with the service or project somehow - at the granularity the specific business requires).
Later, after the services are delivered, an invoice is generated, referring to the former order.
That is usually what happens in several service oriented businesses, so there is this chain
Project - Services - Offer - Order - Invoice
with the project at the very beginning and the invoice at the far end.
From this, the project belonging to an invoice can usually be recreated if necessary. However, which of those relationships you really store in your system in a form which can be evaluated efficiently not just by a human, but also by a software, is a different question! It does not depend on which kind of relationships exist in theory, but which kind of processing the system shall be able to do.
But I am not sure if this is correct and I could have this relation.
It is not wrong, but not the only valid solution. What you need to analyse is the kind of use cases / processes / functions you want to implement in software. If you have mostly use cases which run on projects/services, and others for invoices only requiring some project ID, but not functions from the project's bounded context, then it makes most sense to give each their own BC.
But if this solution is correct, then to know to which project an invoice belongs to, should I have a reference to the ID of the project?
As I said, if you store such IDs, is totally dependend on the processes you want to implement.
For example, you want to provide a use case like this: "Finding out if there are there any unpaid invoices for one specific project". If you don't want someone having to use a global text search to identify the potential invoices for a specific project afterwards (and look manually through some scanned PDF files afterwards), it may be a good idea to store the invoice together with some information where it belongs to whenever it is created. If you store the project ID inside the invoice, or a project ID together with a service number, or just an order number (whilst the order is related to the project somehow) is up to you and maybe also influenced by the way how and by whom these information and references will be entered into your system.
So in short: you cannot answer these kinds of question just by looking at the data. You need to think of the processes you want the system to support, the behaviour of the system, which relationships must be expressed in machine-readable form and which ones can stay there loosely, in a non-strictly defined manner. Also numbers matter: if your business produces one invoice per year per customer for a service which is the whole project, you will have different requirements than when your business produces 500 different invoices per year per customer for 50 different projects, where each project consists of a dozen different services.
