For customer-, client-, partner-, vendor-generated complaints, I also operate on the "always assume the bug is in our code" philosophy. You don't want to go back to a customer (customer, client, partner, vendor) and tell them that it's _their_ problem until you have sufficiently ruled out evidence that it was _your_ problem. In your case above, however, I would have spent a couple of days--max--before going back to the partner and saying "Hey, we've noticed this bug, and we're still investigating things on our end, but we're reasonably confident it's not something on our end. Can you take a look?" This would have saved you months, but also demonstrated to the partner that you've done (and are doing) due diligence to investigate the problem.
But for 99% of interactions, you want to assume you're the one who screwed up. It's safer and it's better customer support.
A similar rule to this is to remove the phrase "it works for me" from your vocabulary. The client wouldn't be complaining about it if it worked for them! So you need to rule out a bug before you go back and say "Hey, actually, you're the one who screwed up." I've found that maybe only 50% of the time is it client error, and so I always operate under the condition that the customer was right until I can prove that they weren't.