Most of the time, I log bugs in our tracking system with reproducible steps and I let developers decide what to do.
However, there are times where I talk to the developer (it is a bug) and the developer comes up with some excuse and say it is AS DESIGNED. Basically, nothing is being logged.
A developer tells me it is AS DESIGNED (verbal agreement) although the functional spec doesn't really say much. But if a customer ends up reporting the same bug then it looks bad on QA. Is there anything a tester can do to protect our reputation? Should I document our verbal agreements and send it to the manager? What is your opinion?
Log the bug. No verbal agreements. Verbal discussions with developers (or PMs or BAs or whomever) are for the purposes of getting a better understanding of how to test things. Once the tests are being run, document what was run and what the results of those runs happened to be. Log all bugs.
If a developer moves your bug to some deferred state such as "Working as designed" and refuses to work on it, then that decision is on him, not you. If a PM or BA agrees with that decision, then the bug will stay there. If they disagree, then the bug will be reassigned and the dev will need to work on it.
If the team decides to leave the bug in a differed state and then, later, a customer reports the bug and NOW the team decides the bug is important, none of them can come back and blame QA for letting the bug into production because you found it and logged it just like you're supposed to.
Ultimately, never take the developer's word for it. Not that they're lying or cheating or out to deceive you (they're not, normally), but mainly because they might have misunderstood the requirements themselves. If the dev misunderstands something and writes bad code based on that misunderstanding, then you ask him what to test and his answer is based on the same misunderstanding, then your tests will (incorrectly) pass the bad code and bugs will get into production. Bad idea. Always go to the source of the requirement, the first link in the chain of information; never go to the last link in that chain.
Only people who create things can be held accountable to the product. Also, no process will fix poor relationship between two parties.
The short answer is you need to put ownership of quality into the development organization. That's something that a strong leadership in testing will need to get buy-in and adoption by the engineering organization as a whole. It's a very difficult task but it can be done. (Look at Google)