I think you bring up great talking points that many struggle with testing modern day API implementations.
As @vdespa has suggested, I agree it’s more of an anti pattern to directly query the database to validate values.
In my personal opinion, and based on my experience, testing is done best when starting off with a clean slate, or a clean instance of the environment, database, etc. It becomes very difficult to truly validate the backends are properly working when the values exist in there without the scope or knowledge of the front end client (in this case Postman), and then a teardown when you are finished, restoring back to its original clean state.
I have always found it easier to initialize my test data using the client that will do the validation. Such that, referencing your prior example, to test the creation of a user, I should first create that user using the client (Postman / your API) and then validate the user was indeed created via a second call, most likely a GET. Same thing with the invoice; it should first be created via the client, and then tested against in a second call or a GET. In your initialization of those values, you can dynamically store the values that you create, so that when you test to see if it actually was created, or the GET, you can validate against those values.
This way its soup to nuts, and your client is agnostic of anything that has happened prior, it just knows what it created, and what it received.
I believe this truthfully tests out the system well enough to validate its behavior.
Now if you don’t actually have an endpoint to validate what has been created via the client, then that becomes a bit more difficult to actually validate, because your testing mechanism will have to be outside of the scope of which the data was initialized to begin with.
I hope this makes sense, or that I wasn’t rehashing something earlier.