You can design the system with a simple query and you can always always change the simple query into an advance query later on, It would be recommended that you try and solve the problem with a simple query, and only when it is completely necessary use an advance query (ie when you find that performance is an issue or other requirements that you can not achieve with a simple query)
The most important part of your application above everything else is getting your database designed correctly/in the right way.
Ricardo: "But...there's always a but, you can make it simple. Why not have a status on the invoice? Because a invoice usually have a life cycle (open, cancelled, suspended and even sometimes payed). Do a static entity named Invoice_Status and make a reference attribute in the Invoice entity.INVOICE"
I would have to agree with ricardo, it would be an ideal choice to have an invoice status in your INVOICE table.
Therefore your invoice tables should look something like this
STATUS (Static Entity)
In the invoice status table, you might have status for "Draft, Sent, Pending, Cancelled, Paid, Paid Partial"
Now you can query your INVOICE table and filter it by status for all paid, all paid partial, all draft, all send, all pending, all cancelled etc.
By the way: you might find the following article useful, Database design with point in time architecture and soft deletes.
hope that helps.