I see what you mean. Should I rather link invoice to customer then?
No, I think that you should just change the annotation on the link between invoice and booking. I'm not sure what annotation you would use in an ERD, because I dislike them so I don't touch them or remember much about them.
There's an injection on invoice into booking, but it can't be surjective and there can't be any complete mapping on booking to invoice, since your description says the invoice is created on departure not on booking; so the mapping in the reverse direction is incomplete, not an injection on booking into invoice. Your annotations seem to say that the relationship include an injection on booking into invoice as well as in the opposite direction, because you mark both directions with "1:1" which is the standard notation in maths (category theory, general algebra, topology, set theory, and relational algebra) to indicate an injection. I would simply remove the 1:1 mark relating to the direction where it isn't appropriate, but I don't know if your style of diagram allows that or not.
In SQL terms, or in terms of Codd's relational theory with nulls, this would man that booking can be a foerign key in invoice, but if you want invoice to be a foreign key in booking you have to allow that field in booking to contain null; in practical database implementation terms you would simply not try to make invoice a foreign key in booking (that's why I pointed out that your not having the field was correct - you hadn't made a very common beginner's mistake), so that you don't hit that problem and don't need to introduce a nullable field - if you want fast discovery of invoice from booking you just provide an index on the booking field of invoice. That of course is also what you would have to do in realtional theory without nulls.