Go with your original design;

StoreKey and InvoiceNumber are your member identifier for aggregation.

There is no need based on your stated problem to have an invoice dimension. If you have other data that is specific to the invoice (i.e. not to the lines) then there is a case to put this data into a separate FACT table but the membership would be the same (StoreKey and InvoiceNumber)

I would only create an invoice dimension if there is something else you need to manage (e.g. sub-orders or multiple delivery dates/locations)